Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative (2022)

c3.handmade.network

Post reply on HN
Print view View original

21–30 of 84 posts

Re: The case against a C alternative (2022)

#21

Post by arnsholt »

friendzis wrote: post #14

The overarching argument in this article seems to be sort of chicken and an egg. > 4. No experienced developers Well, with C you need experienced devs that are also EXPERIENCED IN C. You can write C that compiles but is all kinds of incorrect, usually subtly. Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) cracks this egg a bit…

Yeah, it's not that the hurdles pointed out in this article are wrong, but IMO the jump from "it's very hard" to "it's impossible" isn't convincingly argued. In discussions of the future of C, something along the lines of "C is never going away" is frequently said, which I think is both right and wrong, depending on what precisely you mean by "going away". If you ask me, C is not going away in the same way that Fortran never went away: it's still hugely important for numerical kernels used extremely widely every day, and software like sqlite will continue to be important. But for C as a culturally defining language in computing, I think the tide is already turning.

Re: The case against a C alternative (2022)

#22

Post by whstl »

t43562 wrote: post #20

Why are we using C anyhow? I suggest it's mainly because of established codebases although the fact that it has very few dependencies makes it attractive for systems programming perhaps and low-level. In the case of established codebases the issue is that we don't want to rewrite them because they're huge and not very well designed usually. There are no unit tests or not many and we cannot break ABI compatibility and…

I have the same experience as you regarding progressive migrations, having done quite a few from C and C++ semi-recently. Often progressive migrations are impossible, due to a "unit" being almost the whole program, by having too many small dependencies and little hacks here and there. So you progressively migrate 20% or 30% and it works but then you hit a roadblock and you have to refactor the whole thing, which is already fragile in the first place. Also LLMs don't help here, they choke at this kind of thing quite fast.

No solution, suggestion or wisdom here, just agreement.

Re: The case against a C alternative (2022)

#23

Post by kryptiskt »

kryptiskt wrote: post #19
qsera wrote: post #7

To me the case against a C alternative is simple. C is like Math. It is the fundamental high level language. There can be no alternative.. Rust made the mistake of thinking it can be low level AND safe. It tried to have the cake and eat it too. That will be its downfall.

C isn't an iota more fundamental than say Modula-2. It's just more popular. And C is very bad at being a low level language. There are plenty of things that you can express in assembly that you just can't do in C. And then the platform ABI won't support it, since C can't support it, and it hampers other languages that don't have C's limitations.

A couple of examples what's missing from C from a low level perspective: Multiple return values (why can't I have a function using more registers than rax or the stack to push back more values?), sane varargs, stack manipulation (an enabler for coroutines and a lot more)

Generally, in an ideal low-level language I wouldn't expect to be hampered because the language is designed for a notional abstract machine that doesn't have things like an actual stack and contiguous RAM.

Re: The case against a C alternative (2022)

#24

Post by tialaramex »

epolanski wrote: post #13
stephc_int13 wrote: post #5

As with many things, only time will tell. Zig seems to be most prominent C alternative today, well funded, with some high-profile support, excellent engineering and both a loyal fanbase and haters. That said, as longtime C user, I've been tempted by Jai and Zig and C3, but I am not ready to make the switch yet. The benefits are simply not big enough. And there is something new that was not apparent in when this artic…

As some respectable C developer I know says: the issue with the C "killers" is that the people that already know C, have years, decades and experiences they are unwilling to let go. They can jump across any major systems programming project out there and feel at home. So to win these people you need to have a killer feature that can win them, Rust offers it. The Jai, C3, Zig, etc, do not. Sure, they are better Cs, bu…

> Sure, they are better Cs, but that's not enough to switch.

It's also not always clear they are "better". The Handmade Community, from which this essay and several of these "better C" languages ultimately spring has some weird ideas about what constitutes "better".

Handmade is Casey Muratori's thing. If you understand it as "This one guy did a video essay series and it all got a bit out of hand" it makes more sense. A twenty first century "Life of Brian" but for software engineering. He's not the Messiah, he's just some guy who was asked his opinion.

They're certainly different which is a key requirement to be better that is often not met by "audiophile" technologies, so that's something. Several of them have some Spatial Memory Safety features (ie bounds checking), which is a thing C doesn't provide out of the box for example [but see Fil-C].

I spent decades writing C for money and for pleasure, and I don't write C any more, I write Rust. But then I was never Casey's audience. For one thing of course, by the time "Handmade Hero" was published I was a long way into my career as a programmer, so it's not really "for" me even if I wanted to make video games (I do not want to make video games).

Re: The case against a C alternative (2022)

#25

Post by t43562 »

whstl wrote: post #22
t43562 wrote: post #20

Why are we using C anyhow? I suggest it's mainly because of established codebases although the fact that it has very few dependencies makes it attractive for systems programming perhaps and low-level. In the case of established codebases the issue is that we don't want to rewrite them because they're huge and not very well designed usually. There are no unit tests or not many and we cannot break ABI compatibility and…

I have the same experience as you regarding progressive migrations, having done quite a few from C and C++ semi-recently. Often progressive migrations are impossible, due to a "unit" being almost the whole program, by having too many small dependencies and little hacks here and there. So you progressively migrate 20% or 30% and it works but then you hit a roadblock and you have to refactor the whole thing, which is a…

Absolutely. I don't have the answer either. The effort to get over that last roadblock is just never possible in the commercial setting.

Re: The case against a C alternative (2022)

#27

Post by bluetomcat »

t43562 wrote: post #20

Why are we using C anyhow? I suggest it's mainly because of established codebases although the fact that it has very few dependencies makes it attractive for systems programming perhaps and low-level. In the case of established codebases the issue is that we don't want to rewrite them because they're huge and not very well designed usually. There are no unit tests or not many and we cannot break ABI compatibility and…

> Why are we using C anyhow?

Because "cc prog.c; ./a.out" offers you the most direct way to interact with your system. Because "man 2 mmap" documents a C API. Because "nm" lists your functions and global variables with the exact same names as the C program.

The relative "lack of features" in comparison to its "better" alternatives is what makes it preferable. It lets you concentrate on the inherent complexity of the problem you are solving, and not on the opinions of vocal people online.

Re: The case against a C alternative (2022)

#28

Post by tombardier »

qsera wrote: post #7

To me the case against a C alternative is simple. C is like Math. It is the fundamental high level language. There can be no alternative.. Rust made the mistake of thinking it can be low level AND safe. It tried to have the cake and eat it too. That will be its downfall.

https://spawn-queue.acm.org/doi/10.1145/3212477.3212479

Re: The case against a C alternative (2022)

#29

Post by tialaramex »

kryptiskt wrote: post #23
kryptiskt wrote: post #19

Earlier quoted context omitted.

C isn't an iota more fundamental than say Modula-2. It's just more popular. And C is very bad at being a low level language. There are plenty of things that you can express in assembly that you just can't do in C. And then the platform ABI won't support it, since C can't support it, and it hampers other languages that don't have C's limitations.

A couple of examples what's missing from C from a low level perspective: Multiple return values (why can't I have a function using more registers than rax or the stack to push back more values?), sane varargs, stack manipulation (an enabler for coroutines and a lot more) Generally, in an ideal low-level language I wouldn't expect to be hampered because the language is designed for a notional abstract machine that doe…

Also C isn't well suited to a modern multi-core computer. The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies.

Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" language is it?

Post reply on HN