The case against a C alternative (2022) • Hacker News Board

Re: The case against a C alternative (2022)

#51

Post by inigyou » Fri, Aug 21, 2026, 12:05 PM UTC

tialaramex wrote: post #29

kryptiskt wrote: post #23

Earlier quoted context omitted.

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" la…

What would you add to make it suitable? Large SIMD operations that the compiler could split across cores?

Re: The case against a C alternative (2022)

#52

Post by 6P58r3MXJSLi » Fri, Aug 21, 2026, 12:07 PM UTC

mejutoco wrote: post #46

6P58r3MXJSLi wrote: post #45

Earlier quoted context omitted.

> Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead. at the cost of developing time and workarounds overhead. > And, if it's not possible to prove this statically - you should be heavily questioning the security of that code. or that's exactly the compromise that allows you to develop that software there is no 100% safety with zero overhead it is not possible

The claim was runtime cost > the competing language will have a runtime cost, which often is unacceptable. The problem you now mention > at the cost of developing time and workarounds overhead. Also happens with plain c and the "pay attention" method.

> Also happens with plain c and the "pay attention" method.

not really

there are decades of well known practices to basically cover every possible scenario

the point is Rust doesn't allow to write certain kinds of code or use certain patterns

it's the cost of the boilerplate

it's not that it is hard, it's that it is tedious

and if we throw LLM at the problem, well, we're not talking about 100% safety anymore

Re: The case against a C alternative (2022)

#53

Post by Paul_Clayton » Fri, Aug 21, 2026, 12:07 PM UTC

serbuvlad wrote: post #35

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…

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

I think more recent languages also provide abstractions that reduce the frequency of off-by-one errors. Type systems also seem to have improved.

Unfortunately, even having tools that eliminate simple errors (like spell checkers and grammar checkers in ordinary writing) does not remove reasoning errors or clarity/conciseness issues.

(Efficient resource use is another dimension besides correctness and maintainability. Using an O(NlogN) method versus O(N×N) may be a mistake when N is small, but tools may lack the domain or profiling knowledge to detect such a mistake. Programming languages also seem to generally lack a way to express the importance of tail resource use, so even with profile information a tool might optimize for mean resource use.)

I think more recent languages have also attempted to increase clarity and conciseness by abstraction and consistent syntax. A newer language may also have more idiom consistency (some of the natural idiom divergence may be less more recently with easier communication -- the Internet functioning like cheap books did for spelling?).

I am not a programmer, but I do like thinking about such things.

Re: The case against a C alternative (2022)

#54

Post by CopyOnWrite » Fri, Aug 21, 2026, 12:12 PM UTC

Nice article.

I miss one of the most important points for me:

C is a very easy to learn programming language (I explicitly do not claim that it is easy to write correct/bug free programs in C) and for me even more important: The mental model of a computer/abstract machine that C exemplifies (memory, pointers, pointer arithmetic, functions) is unbelievably useful for understanding and coming to terms with nearly all kind of programming languages/computer programs. Of course the mental model is wrong, but boy is it useful.

Would I start a new project in C if I can help it? Never. Would I use any other language than C if I want to implement a small part of a program which benefits from a C like low level language? I would not say never, but I do not see any candidate language at this moment. Especially because small programs in C IMHO are manageable for a reasonable experienced programmer.

I would love to life in an alternate reality where something like LISP/Scheme would be the basic model of computation (lambda calculus) and everything else would build on this as a useful mental model, though! :-)

Re: The case against a C alternative (2022)

#55

Post by designuki » Fri, Aug 21, 2026, 12:13 PM UTC

serbuvlad wrote: post #35

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…

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

> Basically [Rust] can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice.

Unfortunately, this is not true.

https://fasterthanli.me/articles/a-rust-match-made-in-hell

https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...

Mojo arguably does this better, by having both implicit and explicit destructors, and forcing developers to call explicit destructors, well, explicitly. A lock's destructor must be called manually if it is marked explicit, and thus developers reading Mojo code will presumably not be in doubt about where and when the lock is released.

https://mojolang.org/docs/manual/lifecycle/death/#explicitly...

This is different from Rust. In the following Rust edition 2024 code, the only difference between the two examples is a pair of "{}" around the match subject, but if you run them, one of them deadlocks, due to how temporary lifetime extension is handled in Rust.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Temporary lifetime extension is a mess in Rust, C++ and Zig. It is not a mess in C, more or less, since compound literals are arguably the only feature of C that have something like temporary lifetime extension, so any problems with temporary lifetime extension in C are limited to compound literals.

Re: The case against a C alternative (2022)

#56

Post by dkersten » Fri, Aug 21, 2026, 12:15 PM UTC

serbuvlad wrote: post #35

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…

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

I resisted Rust for a long time too. I’ve been using C++ since 2002 and always liked it especially with the modern additions. I liked the idea of Rust early on and even tried it in little amounts and it seemed nice enough, but then over time it just felt over complicated for not enough payout.

Until I learned it for real and forced myself to overcome the hurdles. Now I love it and find it hard to go back to C++. Why would I want to use any language that doesn’t prioritise safety!? Yes Rust can be complex, because things that are safe sometimes can’t be proven to be safe, and then you need a mindset shift to structure the code in ways where it can be proven safe (or if you absolutely need, unsafe lets you isolate the bits that you have to prove yourself. Many people think what’s the point of rust if it has unsafe, but they fail to understand that 100% of your code in other languages is in a rust unsafe block, while in rust at least only the smallest surface needed has to be).

Anyway, yeah, I’m a convert. As for your last paragraph, it’s true, memory safety (and concurrency safety etc) does not mean bug free. But it does eliminate one kind of common high impact error.

Re: The case against a C alternative (2022)

#57

Post by serbuvlad » Fri, Aug 21, 2026, 12:16 PM UTC

friendzis wrote: post #48

serbuvlad wrote: post #35

Earlier quoted context omitted.

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string fo…

Of course, but many languages do many of these things, and have for decades. C is an outlier for not having them, and many big apps use C++ over C for this reason.

Rust's contribution is static resource-use-correctness. Of course, it also implements the other features very well. But if you do not talk about these things in precise terms, it will be harder to convince people to embrace Rust adoption.

Thankfully, Rust is not doing bad for itself in terms of adoption, so what do I know! :)

But it is what kept me from using it for a long time.

Re: The case against a C alternative (2022)

#58

Post by designuki » Fri, Aug 21, 2026, 12:27 PM UTC

serbuvlad wrote: post #35

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…

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

> cultish

https://lkml.org/lkml/2025/2/6/1292

Re: The case against a C alternative (2022)

#59

Post by tialaramex » Fri, Aug 21, 2026, 12:37 PM UTC

inigyou wrote: post #51

tialaramex wrote: post #29

Earlier quoted context omitted.

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" la…

What would you add to make it suitable? Large SIMD operations that the compiler could split across cores?

I'm definitely the wrong person to ask because my solution was to write Rust.

I think the machines C was conceived for are small enough by today's standards that I would not bring a high level language (like C) to the fight, a macro assembler and you'll be fine. For today's much larger machines, use Rust.

Oh you've got 16-bit addressing? Chart all the addresses and what you'll use them for on a white board or a big sheet of paper. You do not need "allocators" like malloc, that's Steve's job, Steve has a sharpie to "allocate" memory on the chart.

Re: The case against a C alternative (2022)

#60

Post by warkdarrior » Fri, Aug 21, 2026, 12:56 PM UTC

ramon156 wrote: post #33

im beginning to get a soft spot for hand-written articles. I see some typos here and there and it makes me feel all warm inside.

Don't worry, your comment is going into the next training set for ChatGPT. I expect we'll see a "human mode" option soon, where typos are generated every 5-10 sentences.