7 ms·

Ask HN: C Language Successors

For those of you who have experimented with potential C language successors, what are pros and cons and your experiences with them? I am talking about languages like Zig, Odin, C3, Hare, V and possibly Nim and Crystal, assuming that they are considered systems programming languages.

yawpitch 2y ago
I think you might want to provide a working definition of what precisely you mean by “successor” here.
- sim7c00 2y ago
  i think (a guess) he'll mean some language that has replaced C for your system programming endevours. not actually c++ or such a type of successor (if c++ can be called that)
  - yawpitch 2y ago
    Probably, but “language you can use instead of C” is a very open field, from APL to Zig at least, passing through D and COBOL and Erlang and Forth, and gets even wider if your definition of “system programming” isn’t particularly well-specified. Replacing C as the lingua Franca of systems programming is a much bigger problem than what language you might consider writing a particular system in instead of C.
fithisux 2y ago
you forgot betterC (D-lang subset)
sylware 2y ago
All I know, is those "successors" should have a simpler syntax than C (since its syntax is already way too complex), and should have pointers, no garbage collection, no hard dependency on a complex runtime, etc. Basically, it should be reasonable for one average dev to write a naive compiler in a reasonable little time. Maybe it is better to cleanup the C syntax a bit: only sized types (u8/16../u64, f32/f64, s8...) namely inverting the primitive types; no implicit cast (except from literals and void*) or integer promotion, real hard compiler constants (re-definition of const keyword?); no switch keyword; only one loop keyword (loop {}); a clear split between static cast and runtime/dynamic cast? (should give more thoughs to it, since only static cast seems to mean something); all those _generic, typeof, restrict, TLS, packed attribute (or how to lose the importance of alignment from sight), anonymous code block, stuff which have to go away; nowdays you need inline atomic, barriers, offsetof; and all the other things I am forgetting and of course if actually doing it, more thoughs will be required. In the meantime I am coding RISC-V assembly which I can run an x86_64.
deleted 2y ago
[deleted]
sim7c00 2y ago
i think it depends a bit on your use case. wont go into too much detail because im definitely not an expert, but i found all alternatives that i managed to compile 'bare metal' code with really tricky and weird to learn to write such code. this is ofcourse not the only kind of system programming, and things i tried might be suitable for other domains of system programming perfectly fine. its likely lack of knowledge on my part, but i found it incredibly tedious to either reason about how binaries in such languages really worked, getting their toolchains to spit out binaries of the type i needed, or having to reimplement a lot of the core libraries which make those languages appealing, the last for example less needed when working within another operating system's execution environment. ultimately i ended up going back to C after many failed experiments. but this is just my 'taste'. likely others might be more succesful (professional system programmers?) i did not find a good alternative to C + assembly yet.
josh_ring 2y ago
I liked C3 a lot because it was the first C successor I looked at which I could understand easily and was relatively more C-like than the others. I have used that property to port various C libraries to C3 without much issue. In Zig I had a really hard time getting productive. I found it really hard, but I really wanted to like it, I just couldn't. Hare was focused on just Linux and I wanted cross platform and ideally a C-like language. Odin looks approachable but I didn't really want a language which is quite different to C as it makes porting code from C more challenging.
purple-leafy 2y ago
What’s wrong with C itself? I’m going back to C myself, to do some graphics programming
iExploder 2y ago
Zig is nice, but subjectively I find some of the syntax is a bit weird, like ?'s !'s and the various array notations. I guess it just takes some time to get used to.
oulipo 2y ago
I quite like Swift

yawpitch 2y ago

I think you might want to provide a working definition of what precisely you mean by “successor” here.

sim7c00 2y ago
i think (a guess) he'll mean some language that has replaced C for your system programming endevours. not actually c++ or such a type of successor (if c++ can be called that)
- yawpitch 2y ago
  Probably, but “language you can use instead of C” is a very open field, from APL to Zig at least, passing through D and COBOL and Erlang and Forth, and gets even wider if your definition of “system programming” isn’t particularly well-specified. Replacing C as the lingua Franca of systems programming is a much bigger problem than what language you might consider writing a particular system in instead of C.

fithisux 2y ago

you forgot betterC (D-lang subset)

sylware 2y ago

All I know, is those "successors" should have a simpler syntax than C (since its syntax is already way too complex), and should have pointers, no garbage collection, no hard dependency on a complex runtime, etc. Basically, it should be reasonable for one average dev to write a naive compiler in a reasonable little time. Maybe it is better to cleanup the C syntax a bit: only sized types (u8/16../u64, f32/f64, s8...) namely inverting the primitive types; no implicit cast (except from literals and void*) or integer promotion, real hard compiler constants (re-definition of const keyword?); no switch keyword; only one loop keyword (loop {}); a clear split between static cast and runtime/dynamic cast? (should give more thoughs to it, since only static cast seems to mean something); all those _generic, typeof, restrict, TLS, packed attribute (or how to lose the importance of alignment from sight), anonymous code block, stuff which have to go away; nowdays you need inline atomic, barriers, offsetof; and all the other things I am forgetting and of course if actually doing it, more thoughs will be required. In the meantime I am coding RISC-V assembly which I can run an x86_64.

deleted 2y ago

[deleted]

sim7c00 2y ago

i think it depends a bit on your use case. wont go into too much detail because im definitely not an expert, but i found all alternatives that i managed to compile 'bare metal' code with really tricky and weird to learn to write such code. this is ofcourse not the only kind of system programming, and things i tried might be suitable for other domains of system programming perfectly fine. its likely lack of knowledge on my part, but i found it incredibly tedious to either reason about how binaries in such languages really worked, getting their toolchains to spit out binaries of the type i needed, or having to reimplement a lot of the core libraries which make those languages appealing, the last for example less needed when working within another operating system's execution environment. ultimately i ended up going back to C after many failed experiments. but this is just my 'taste'. likely others might be more succesful (professional system programmers?) i did not find a good alternative to C + assembly yet.

josh_ring 2y ago

I liked C3 a lot because it was the first C successor I looked at which I could understand easily and was relatively more C-like than the others. I have used that property to port various C libraries to C3 without much issue. In Zig I had a really hard time getting productive. I found it really hard, but I really wanted to like it, I just couldn't. Hare was focused on just Linux and I wanted cross platform and ideally a C-like language. Odin looks approachable but I didn't really want a language which is quite different to C as it makes porting code from C more challenging.

purple-leafy 2y ago

What’s wrong with C itself? I’m going back to C myself, to do some graphics programming

iExploder 2y ago

Zig is nice, but subjectively I find some of the syntax is a bit weird, like ?'s !'s and the various array notations. I guess it just takes some time to get used to.

oulipo 2y ago

I quite like Swift