This doesnt seems to be meaningfully different from Rust.
> does not require tracing garbage collection
Just call it garbage collection.
(Applies in two ways: if you think that garbage collection subsumes reference counting then this language doesn’t require garbage collection in the sense that it also doesn’t require reference counting; if you think that garbage collection does not subsume reference counting then there’s no point in saying three words when you can say two.)
It's less specified than rust. For example, you can bind references to individual collection elements here. It doesn't seem to prohibit borrowing a dynamically indexed element either, which is one hell of a static analysis lift. Seems like you can also have simultaneous references to distinct static indices (e.g. &mut arr[0] and &mut arr[1]) as long as you don't do invalidating operations, which isn't expressible in NLL or polonius. That's feasible for a borrowchecker at least.
i reckon it's easy enough to alias the stdint.h types and define them in terms of the size definitions above. i'd forgotten that the C3 pointer types are the ones whose bit size varies by platform. mea culpa.
It's great to have it all spec'd out. However, I think specs like this suffer the same fate as war plans: they get modified quickly as soon as implementation begins. Nonetheless, it's good to have a clear idea of where you're headed. I just wouldn't call it "Final."
According to ChatGPT, the CobaltC language specification does now (since the spec was recently updated with an errata) provide sufficient syntactic, structural, and semantic boundaries to begin high-level compiler implementation planning, despite intentionally leaving lower-level mechanical decisions to the developer.
Yes, but remember is the last appendix to a book, and book provides the context for this appendix. So yes, in that sense, it's just another one attempting to address the memory-safety issues of C. At least this one uses C like syntax and doesn't require C programmers to learn some alien syntax. Of course, this is just a spec, Rust is well and truly live in the environment. The book is more interesting than the spec.
This is so obviously written by ChatGPT from what I can tell. Not even an attempt to copyedit it unless I missed something.
I’m not sure about copy but the UI seems designed to look like an AI response which is certainly a choice
...and UI is clearly spotable as AI generated with whatever tool....
This doesnt seems to be meaningfully different from Rust.
> does not require tracing garbage collection
Just call it garbage collection.
(Applies in two ways: if you think that garbage collection subsumes reference counting then this language doesn’t require garbage collection in the sense that it also doesn’t require reference counting; if you think that garbage collection does not subsume reference counting then there’s no point in saying three words when you can say two.)
It's less specified than rust. For example, you can bind references to individual collection elements here. It doesn't seem to prohibit borrowing a dynamically indexed element either, which is one hell of a static analysis lift. Seems like you can also have simultaneous references to distinct static indices (e.g. &mut arr[0] and &mut arr[1]) as long as you don't do invalidating operations, which isn't expressible in NLL or polonius. That's feasible for a borrowchecker at least.
Before I read this, what is there about C3 [0] you don't like?
[0] https://c3-lang.org
C3 is an embarrassing mess regarding integer types and sizes, missing C99's stdint.h defs, for example.
To clarify: C3 has fixed sized ints. Maybe the parent poster doesn’t like their names, but they are fixed sized, as follows:
Source: https://c3-lang.org/language-overview/types/#integer-types
i reckon it's easy enough to alias the stdint.h types and define them in terms of the size definitions above. i'd forgotten that the C3 pointer types are the ones whose bit size varies by platform. mea culpa.
Unsafe identifiers, prone to homoglyph attacks. No TR39 provisions. Worse than rust or Java. https://strawberry9.github.io/the-wrong-memory/Appendix_06.h...
It's great to have it all spec'd out. However, I think specs like this suffer the same fate as war plans: they get modified quickly as soon as implementation begins. Nonetheless, it's good to have a clear idea of where you're headed. I just wouldn't call it "Final."
reads more like a Wishlist rather than actual implementable specs.
every spec is implementable
some just delegate more or less to the implementation
that said, the borrowing part is incredibly short on details
i read trying to assess if it's more or less expressible than rust's current nll or the future polonius and honestly there's nothing there
According to ChatGPT, the CobaltC language specification does now (since the spec was recently updated with an errata) provide sufficient syntactic, structural, and semantic boundaries to begin high-level compiler implementation planning, despite intentionally leaving lower-level mechanical decisions to the developer.
This is certainly copying off Rust's homework...
Who copied off Haskells homework, so here we are.
And cloudflare still somehow shipped a rust binary that crashed half the internet.
and I've had Haskell binaries attempt to use infinite quantities of RAM (looking at an old version of dconf2nix here) and thus crash
Another one?
Yes, but remember is the last appendix to a book, and book provides the context for this appendix. So yes, in that sense, it's just another one attempting to address the memory-safety issues of C. At least this one uses C like syntax and doesn't require C programmers to learn some alien syntax. Of course, this is just a spec, Rust is well and truly live in the environment. The book is more interesting than the spec.
Odin's turn to be "the sucessor of C" is due this month