Yeah, I have used Odin before, I am thinking of giving C3 a try as well.
At a quick glance though:
> Enum support various reflection properties: .values returns an array with all enums. .len or .elements returns the number of enum values, .inner returns the storage type. .names returns an array with the names of all enums. .associated returns an array of the typeids of the associated values for the enum.
I do not like that the length is named ".elements" instead of just ".len". And why are there two ways, or are they not the same? Etc.
FWIW I have spent the weekend testing out C-replacement languages and their interop (linking to libsdl3 and libtcl) with D, Go, Rust, Odin and C3. My quick impressions:
- D is featureful, but too much so. It feels an unfocused kitchen sink worse than C++. Overall the actual dev experience was nice.
- Go I know pretty well, but saddened that CGo is very slow, so I cannot consider it truly a C replacement
- Rust I also know decently well, but writing types and lifetimes isn’t my idea of fun. I’d rather have less safety when playing with code, I’m not always writing mission critical apps. Overall walks the fine line between excellent and unergonomic; pulls half a gig of dependencies just to include SDL3 which is pure madness.
- Odin I have played with before, excellent for the gamedev world, but some features seems like they have been added just because the author liked them. Having to explicitly set up the context variable in cdecl callbacks feels bad. I dislike the whole context thing actually, because it is rigid though convenient.
- C3: documentation is bad but feels the closest to a better C. Still in the breaking phase, I sent a PR this morning to adapt the SDL3 library to the latest release. Has macros which I haven’t tested but it’s a big plus. Some syntax makes no sense, like block labels and generic in {braces} but it’s the one I will keep playing with for this project. No one seems to use or know about it, which doesn’t bode well for its future.
- Zig I haven’t used this weekend, I loathe that unused variables are errors and it is very verbose. Docs and stdlib are way undercooked. comptime is a brilliant idea. Could be decent past 1.0 release.
- Jai: I’d love to try it, if I had access to the beta.
A lot of paper cuts and small issues, nothing is really worthy of being called a C replacement, but I do not want to write another header file again so these will make do for now.
Thanks for sharing! I think there is hope for C3, if they do not mind breaking backwards compatibility, which I hope they do not, for now!
We have similar experiences I would say. I do like Go a lot, but I rarely had to touch CGo though. The language does not get in the way of being productive. Rust seems like it does.
I would give Jai a try, too!
Have you tried Zig, or perhaps even Nim? Curious about your thoughts.
Nim I played a bit with, I don’t really like the syntax but I admit I need to dive deeper. My other issue is that it is so different syntax wise to C, and sometimes so high-level, it’s hard to tell what construct is efficient, and what allocates and takes 500 instructions to run. This is pretty crucial for a low level system language.
Oh `.elements` would you believe that this is a remnant of C2's builtin function `elemsof`? Its used so rarely (I think two uses in the entire stdlib), so it hasn't come up. I opened an issue for it: https://github.com/c3lang/c3c/issues/2130
This is a good example of the sharp edges I hope to smoothen out in 0.7-0.9.
At a quick glance though:
> Enum support various reflection properties: .values returns an array with all enums. .len or .elements returns the number of enum values, .inner returns the storage type. .names returns an array with the names of all enums. .associated returns an array of the typeids of the associated values for the enum.
I do not like that the length is named ".elements" instead of just ".len". And why are there two ways, or are they not the same? Etc.