alt.hn

8/16/2026 at 3:17:09 PM

The case against a C alternative (2022)

 https://c3.handmade.network/blog/p/8486-the_case_against_a_c_alternative

by theanonymousone

8/21/2026 at 9:44:44 AM

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.

> If you want to target some obscure platform, then likely it's assuming you're using C.

Some (most?) obscure platforms offer a fork of GCC, yes. With LLVM frontend becomes less and less relevant. This particular chicken and an egg is being broken with or without a successor to C.

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C.

This argument is circular. There are indeed some scenarios where you do absolutely need "macro system for assembly" to do some weird shit, but typically that is a relatively small part of the whole project. Unsafe modes help tackle this small need. The argument reads like needing C-ish language for some little parts of your project requires to use C-ish language for the whole project.

> 3. Programmer productivity

This whole argument is weirdly focused. In my experience, a huge chunk of effort is spent on rework. Any language that improves turnaround rate improves productivity on feature level. The argument again assumes that devs manage to produce correct code without turnarounds (which is rare in practice even with highly experienced devs) and therefore any new language would increase turnarounds. Safety and productivity features are usually designed to increase quality without expertise-floor.

by friendzis

8/21/2026 at 10:09:51 AM

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.

by arnsholt

8/21/2026 at 10:46:06 AM

> But for C as a culturally defining language in computing, I think the tide is already turning.

The problem still is which language will replace C here.

C++ won't.

Neither will Rust or Java.

So which language will replace C here?

I agree that C and Fortran can not be compared really. C will remain for a very long time to come.

by shevy-java

8/21/2026 at 11:09:41 AM

> 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 incorrect code, nor is this possible (halting problem).

What Rust can do is enforce a very specific type of correctness, which may be termed resource-use-correctness. Basically it 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.

This ability is extremely valuable!

But it is also quite easy to write incorrect buggy programs in Rust, for the very simple reason that it is very easy to write incorrect buggy programs that do not misuse their resources.

by serbuvlad

8/21/2026 at 12:15:17 PM

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.

by dkersten

8/21/2026 at 2:14:15 PM

How do you feel about pinning in Rust, and how comfortable are you with the aliasing rules of Rust when working with unsafe Rust?

by designuki

8/21/2026 at 12:07:26 PM

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.

by Paul_Clayton

8/21/2026 at 12:03:40 PM

> 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 for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect.

Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that.

> Rust cannot prevent incorrect code, nor is this possible (halting problem).

Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround.

Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.

by friendzis

8/21/2026 at 12:16:05 PM

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.

by serbuvlad

8/21/2026 at 12:13:21 PM

> 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_...

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...

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.

by designuki

8/21/2026 at 8:53:29 AM

Pretty unconvincing arguments overall. Mostly boils down to "any new language will start as new and not mature". Dismisses any "killer feature" in C's design space. Ignores that there is already a well established C alternative: C++.

But obviously nothing will replace C in the sense that C will cease to exist.

by leni536

8/21/2026 at 9:34:08 AM

> Ignores that there is already a well established C alternative: C++.

I don't consider C++ an alternative to C.

I see it as "a more modern language", but there are "even more modern" languages nowadays. The only reason I see to pick C++ instead of something like Rust would be if there are very mature C++ libraries and it is not practical to call them from the newer language. Typically for computer vision (or maybe just linear algebra?), I would still go with C++, probably? But in terms of language, I would pick any modern language over C++ if they do the job.

What about C, then? I use C when I want interoperability. Nothing currently beats C in that domain, as far as I know. I often wrap whatever I have into a C interface just for that.

IMHO, the interesting question about "replacing C" is really this: if you had to design a modern language meant to compete with C's interop story, how would it look like? Not sure if such a language could have memory-safety, for instance? Could such a language be meaningfully nicer than C?

Disclaimer: I don't know Zig.

by palata

8/21/2026 at 9:45:03 AM

> Ignores that there is already a well established C alternative: C++.

The key point is, C++ added numerous features to C, and at the time, it was the only language occupying that position (or perhaps Objective-C, too?).

Today, a successor to C cannot simply replicate what C++ did. Add too many features, and it will be viewed as a successor to C++ rather than to C (as is the case with Rust and D). Conversely, keep the additions minimal in order to stay close to C, and you end up in a "red ocean" crowded with Zig, Odin, C3, Hare, Jai, and others.

by mjyut

8/21/2026 at 11:13:15 AM

This one struck me in particular as unconvincing:

> The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

Why would all possible checks that provide an improvement over C be runtime-only?

by msdz

8/21/2026 at 9:35:53 AM

> My language (C3) is fairly recent, there are others: Zig, Odin, Jai and older languages like eC. Looking at C++ alternatives there are languages like D, Rust, Nim, Crystal, Beef, Carbon and others.

He acknowledges C++ in the first paragraph ...

He's obviously writing this from the point of view of making a case against what he is doing, which is creating a new language (C3). Interesting perspective considering that this was written just before the LLM hype kicked off. It would be interesting to get an update in that context: why create a new language when AIs are going to be the primary user and what would be killer features for AI coding tools to use? It seems languages like Go and Rust are relatively popular targets for using with such tools. C/C++, not so much (other than for code rewrites in Rust).

by jillesvangurp

8/21/2026 at 9:11:40 AM

We also have D and Zig and Rust. Or even OCaml or Forth, depending on what you see as essentially about C.

by eru

8/21/2026 at 9:34:23 AM

> obviously nothing will replace C in the sense that C will cease to exist.

Long-term it almost certainly will. But not in our lifetimes, sure.

by nicoburns

8/21/2026 at 9:36:25 AM

To me, the value of C is the interop story.

Is there a modern language with ABI stability that can replace C for that? As in, you can wrap anything with a C API and be sure that it can be called from any other language easily?

by palata

8/21/2026 at 9:55:36 AM

The interop story is largely a self-fulfilling prophecy. When you start to explore the edges of C ABI compatibility you discover that er... there's actually no ABI compatibility unless somebody did the work and they never did the work.

Two C implementations on the same CPU with 64-bit integers both, unsurprisingly, think 64-bit integers work the same way - because that was obvious. Now, how about 128-bit integers. Ah, turns out implementation A thought they go (lo,hi) but B thought they're obviously (hi,lo) so these types have different ABI between C implementations...

It's not obvious because most software which cares about Windows also needs the Windows API and so couldn't be non-Windows software, but Windows people have a different rule for how 64-bit works than everybody else, LLP64 versus the usual LP64. And there were other options such as ILP64 they're just all basically dead.

by tialaramex

8/21/2026 at 11:17:24 AM

128-bit integers aren’t part of the standard (yet)… but the point is right; platform and architecture matter. Many aspects of them are defined by the compiler implementation.

Also ABI compatibility isn’t part of the C specification. Most implementers use System V ABI compatibility guidelines. Many compilers can output code for different ABI’s calling conventions. There’s more than one! Which you use depends on how crufty the code is and on the platform you are using.

I think the big advantage of C like languages here is the plethora of implementation defined platforms. That’s a huge network effect. If you want to target the 6502? There’s a compiler for it. Some chip you’ve never heard of? Probably some fork of GCC that targets it. Want to call some library function in some foreign binary written in a completely unknown language? If you can finagle the bytes and reverse engineer the calling conventions you can do it with C.

I think it might be that C does leave so much out of the specification and up to the implementation and platform that makes it unique and useful at times.

by agentultra

8/21/2026 at 11:11:56 AM

Somebody did do the work! The System V AMD64 ABI definitely defines the registers for __int128, e.g. as first argument to a function it will always be rdi (lo) rsi (hi) and for return value it will always be rax (lo) rdx (hi).

by P-Nuts

8/21/2026 at 1:01:59 PM

See the author's more recent post "I thought I was building a C replacement. I was wrong": https://c3-lang.org/blog/i_thought_i_was_building_a_c_replac...

Of note, C3 is alive and well, with the latest release (0.8.3) just last week.

I stumbled upon the language earlier this year and love it. I like plain C a lot, but it's a rough experience. Having slices, modules, a strong stdlib and memory management massively improve the experience. The compiler is a 2MB binary compared to the ridiculously huge Rust/Cargo toolchain. I also found LLMs to be really good at writing it, made a simple skill [1] that gets even Claude Haiku to write correct code. Have been using it for several projects and really enjoying it.

[1] https://github.com/ricardobeat/skills/tree/main/c3-lang

by ricardobeat

8/21/2026 at 12:12:22 PM

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! :-)

by CopyOnWrite

8/21/2026 at 9:32:22 AM

I am guilty in a sense, I started a new programming language called C+ and one of the pillars I set was that it should not be an alternative to C (or any other language), in fact it uses Clang as its compiler, most of the points in the article still hold, but I hope it doesn’t stop people from coming up with new ideas and actually implementing them in this field, you don't have to be next big thing to be awesome

by netdur

8/21/2026 at 9:53:56 AM

I like to program in a C++ subset that's basically C plus a sprinkling of ergonomic quality of life C++ features eg references and generic containers. I think of it as C+.

(Edit: No disrespect meant. I just thought such completely different language concepts potentially sharing the same name was kind of amusing)

by billforsternz

8/21/2026 at 11:57:33 AM

Almost everyone that uses C++ uses a subset of C++ and it's always a different subset. (That's fine, that's because it's a "big tent" language philosophy)

by inigyou

8/21/2026 at 11:30:15 AM

no worry, name is intentional, it's C + packages, language itself is tiny, strictly bounded by the C ABI, and doesn't include most of the features you'd expect in a language, even standard library is just a external package, so it's not a subset of C++ at all

by netdur

8/21/2026 at 11:57:20 AM

> The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

This problem is overstated. There's no safety/performance tradeoff here. Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead.

For a concrete example, checking that an array access is in bounds at runtime does come with a performance penalty. However it's also possible to prove at compile time that an array index can never escape it's array bounds. And, if it's not possible to prove this statically - you should be heavily questioning the security of that code.

by hanneshdc

8/21/2026 at 1:03:50 PM

The safety/performance trade is actually, once you think about it, obviously nonsense in principle. All correct solutions will be memory safe so only incorrect programs are unsafe. At that point it can't have better performance, the wrong answer faster is useless - I always come back to Mushroom Office: https://x.com/magdraws/status/1551612747569299458

WUFFS provides strong concrete evidence. A WUFFS image decoder is entirely safe because that was the whole point, but it's also a lot faster because since we've proved this is safe we don't need any of these safeguards and precautions you'd want in languages which aren't sure. We cannot do anything wrong, so there's no need for the compiler to add bounds checks for example never mind Fil-C's "shadow" memory.

Now, WUFFS pays a price for that, it's not a General Purpose Language. You can't write "Hello, World" in WUFFS because it doesn't have strings for the message or I/O to emit the message somewhere. But we should be clear eyed about how much we're paying when we insist we need generality. Not just safety, performance.

by tialaramex

8/21/2026 at 11:59:53 AM

> 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

by 6P58r3MXJSLi

8/21/2026 at 12:02:26 PM

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.

by mejutoco

8/21/2026 at 12:07:20 PM

> 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

by 6P58r3MXJSLi

8/21/2026 at 11:20:57 AM

Or you can just stick to C, but do it in a completely memory safe way. Fil-C is the answer[0]

[0] https://fil-c.org/

by sgt

8/21/2026 at 9:46:47 AM

For me c is a common ground any feature can be build of. It is very easy to read without much knowledge and has a big base of knowledge around for decades. Anything better than c was in my opinion a WOMBAT. Waste of money brain and Time

by Surac

8/21/2026 at 11:01:07 AM

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.

by ramon156

8/21/2026 at 12:56:16 PM

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.

by warkdarrior

8/21/2026 at 9:17:57 AM

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 article was written: a lot of code is LLM written now, giving old and mainstream language an undeniable advantage. Also, Rust, with the built-in safeguards, is pretty AI assistance friendly.

by stephc_int13

8/21/2026 at 9:41:40 AM

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, but that's not enough to switch.

So eventually, all those C killers will keep growing, among newer system programmers, but not much among seasoned C devs.

by epolanski

8/21/2026 at 10:23:23 AM

> 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).

by tialaramex

8/21/2026 at 11:57:36 AM

I think the first argument of there being a good toolchain is nonsense, obviously there was something before C with a great toolchain.

by octocop

8/21/2026 at 9:33:35 AM

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.

by qsera

8/21/2026 at 9:56:18 AM

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.

by kryptiskt

8/21/2026 at 10:19:04 AM

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.

by kryptiskt

8/21/2026 at 10:35:11 AM

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?

by tialaramex

8/21/2026 at 12:05:28 PM

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

by inigyou

8/21/2026 at 12:37:45 PM

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.

by tialaramex

8/21/2026 at 1:32:05 PM

Ironically I think to make the best use of such a small memory window, you'd want a compacting garbage collector. Lots of the 16-bit era BASICs used compacting GC for their strings.

Yes you can statically allocate, but who wants an artificial limitation like "16 strings, 256 bytes each" when some users want 200 strings of 8 bytes and some users want 4 strings of 500 bytes. Static allocation is something you can do when your memory is large compared to your use cases.

by inigyou

8/21/2026 at 1:37:43 PM

> 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.

Isn't Rust's solution mostly the same, just with C++20?

https://doc.rust-lang.org/nomicon/atomics.html

> Rust pretty blatantly just inherits the memory model for atomics from C++20.

by designuki

8/21/2026 at 11:03:21 AM

Mathematics has much less tolerance for "undefined".

> thinking it can be low level AND safe.

"low level and unsafe" is something that people will eventually get tired of once there is a big enough disaster. Or at least start slapping Prop 65 warnings on unsafe products.

by pjc50

8/21/2026 at 2:21:57 PM

> 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.

Ridiculous take

by mcronce

8/21/2026 at 12:04:38 PM

C has a high level assembly language at its roots - almost every other language does not. That's what makes it fundamental. But someone else could design a different high level assembly language.

by inigyou

8/21/2026 at 2:06:26 PM

C doesn't provide an assembler at all. So if your C implementation provide an assembler that's a non-standard extension. What do you get? It depends, can you use it with a different compiler for the same target? It depends.

So probably you're instead thinking "C is like an assembly language" and that's entirely wrong. The C abstract machine is very weird. No machines exactly like that have ever existed or will ever be built, so you're not programming a real machine. The closest ones were in the 1970s, machines today are very different.

IMO the worst outcome of this "Oh C is just assembler" nonsense is the compound volatile operations.

You probably imagine a line of C like `foo |= 1` ensures `foo` has the LSB set right? You may or may not realise that "Set the LSB of a location in memory" isn't an operation most CPUs have but hey, in C it was a single operation so...

As a hack when compilers got smarter C also has a "volatile" type qualifier, so `foo` can have the type qualifier "volatile" meaning that updates to this variable will definitely happen in memory, the compiler won't just keep `foo` in a CPU register to accelerate things, it has promised to write it back to memory...

So now, `foo |= 1` looks like a single CPU operation which should set the LSB of foo. But of course your CPU probably can't actually do that, so what's really emitted by your C compiler is read foo from memory into a CPU register, set the LSB of that register and then write the whole register back to memory. Which is three distinct operations in sequence, and thus now it can be interrupted by other work and then carry on, despite the fact that meanwhile foo changed...

Oops. The C looks fine, but the machine code generated may introduce a massive bug.

If you do want a language with assembly, Rust provides that. It provides both inline assembler which you can use inside your Rust functions, and bare assembly. Of course that's not safe Rust, but presumably if you wanted to write assembly you were on board with taking the responsibility.

by tialaramex

8/21/2026 at 9:37:11 AM

There's plenty of alternatives out there, the downfall you see is imaginary.

Nice ragebait tentative though.

by epolanski

8/21/2026 at 9:59:59 AM

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 so on. So change has a risk. Also you're trying to get other developers to agree to the change and they are often in a post-nuclear-war state about other technical decisions and certainly don't want to start another one about some language they don't understand.

What we really need is some way to progressively improve big codebases without having to swallow a huge pill. In other words I need to be able to work a file at a time with something that fits exactly into the build system that is building the C code.

At the moment I'm using ESQL to embed Informix queries - this is a subtly quite good language extension that certainly makes life better except of course that it ties us to a specific expensive database etc etc. As an improvement on C it works in it's limited sphere.

In this huge project there's so much code that it's hard to know what's the right way to do anything and the same solutions have been written again and again in slightly different ways.

Half the libraries have circular dependencies such that they only build with an odd little trick and it's extremely difficult to know the precise reasons why this design evolved or how to begin unpicking those dependencies. Without tests any change could be a disaster.

One established way of improving on C is to use a DSL or something like embedded TCL such that most of the time you're not actually writing C. The current project went the DSL route and it's very very much better than nothing but without a grammar the parser is hard to maintain. I've been on a project using TCL and that was excellent - loading and parsing a config file, for example, is something one almost never really needs to do in C and there are many bits of a program that TCL can do much more reliably and perfectly fast enough.

This ramble is trying to convey that a new language presents a problem to people who have 100 problems already. If you can make it help with those 100 problems then it will win.

Successful example: Converting to Git from SCCS is a huge pain but I've just done it (had to infer changesets from individual file version usernames and dates and times :/ ) but Git is well worth the trouble because it's so much less stressful to make mistakes with and vastly easier to do reviews and so on.

by t43562

8/21/2026 at 10:33:07 AM

> 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.

by bluetomcat

8/21/2026 at 10:18:42 AM

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.

by whstl

8/21/2026 at 10:26:41 AM

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

by t43562

8/21/2026 at 11:32:53 AM

Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything.

Rust was made to replace C++ because the language it's a behemoth, it tries to do everything and the syntax it's a Lovecraftan nightmare, full of legacy incompatibilities. For small games such as Cataclysm:DDA I'd use Go (and for system tools and internet services OFC) and for game engines Rust it's or even GC based languages (not Java) can do it well (C# with AOT).

Even Common Lisp it's fine (just look up Trial/Kandria) with SDL2/3 and/or OpenGL bindings (Vulkan ones should be somewhere). Pick SBCL for speed, learn CL, learn about SIMD and optimizations. It can beat C on performance.

https://www.stylewarning.com/posts/nbody/

EDIT: the bindings are cl-vulkan, of course.

by anthk

8/21/2026 at 12:04:36 PM

There are times that JIT'd C# out-performs AOT C#, so I'd avoid defaulting to recommending AOT. Assuming that AOT is faster is the same trap that C advocates fall into when thinking that other languages can only ever equal C on speed.

by xnorswap

8/21/2026 at 1:02:08 PM

If a language can produce the same machine code (including dynamic patching) as a second language, that second language can at best only equal the runtime characteristics of the first. The development and maintenance costs can be very different.

I am not certain if C (apart from inline assembly) can generate all possible machine code, and some translations can be fragile (autovectorization, e.g.).

by Paul_Clayton

8/21/2026 at 1:27:00 PM

Well indeed, which is why I don't really like talking about the "speed" of a language at all. What really matters is the characteristics of the idiomatic usage.

by xnorswap

8/21/2026 at 10:44:57 AM

Several of the arguments are not compelling.

For instance:

"The C language is not just the language itself but all the developer tools developed for the language. Do you want to do static analysis on your source code?"

This is a finite problem set. For instance, AI could auto-create useful toolings eventually. And even without AI, people can. Even more so if a new language is designed with that in mind from the get go. So, perhaps it would be a lot of effort, but this is really not the reason why C is so dominating.

> The uncertainties of a new language

> Before a language has matured, it's likely to have bugs and might change significantly to address problems with language semantic.

Here I somewhat agree. Another language is different, that is true, and may not be better, that is also true. I am still not convinced Rust is better than C, for instance.

However had, I also don't this this as unsolvable. Many new languages are in part better than C. I mean, I notice this when I write ruby code and C code. Let's ignore the speed problem; and the fact that ruby is written mostly in C (which kind of shows that C dominates everything). The ruby code I write is about 1000000000x easier to understand, simpler and almost always shorter than C. There is no comparison here. Ruby is the better programming language. C is faster and more efficient. And this is also significant. My prediction is that a language that would be able to replace C, needs to target both the speed issue without compromise AND the efficiency of writing code, be it ruby-like, python-like and so forth. And neither of these two languages try to replace C either, so they don't quite count here.

> And what about maintainers? Sure, an open source language can be forked, but I doubt many companies are interested in using a language that they further down the line might be forced to maintain.

This is a problem, but you have this problem with corporations too. For instance, Go is controlled by Google, as is Flutter/Dart. Google can babble that everyone can contribute but the reality of the situation is that Google decides what happens; same with the adChromium code base. Personally I really don't want corporations to dictate their world view onto a language. Committees can also have problems or be bribed and what not, we can see the chaos in the C++ committee too, even without bribery - stupidity often rules supreme. But by and large, I much prefer single benevolent dictators or indepedent (as much as possible) committees than mega-evil mega-huge greedy corporations controlling a language. This does not automatically mean a language is better or worse, either way, but it is a preference for me. And I know for a fact that many others somewhat or strongly agree with this too, except a few die-hard Google fanbois (but most of them are employed by Google anyway, so their "opinion" does not count; I see the same problem with shopify and ruby, by the way, it's really interesting).

> 3. The language might just not be good enough > Is the language even addressing the real pain points of C? It turns out that people don't always agree on what the pain points with C is.

Yup, that is also true, see Rust. On the other hand, I think cargo is really useful, and even C++ agreed. I think C also did not that long ago, but boy, for many decades C thought that easy download of add-ons is not needed. C changes very slowly. I understand that this is often nice, but just as in the example of cargo and what not, this was really STUPID of C to not change here.

Other than that I agree on the general point. Many changes are also idiotic in other languages. Ruby incorporated many idiotic changes too; thankfully I can avoid most of them so I just ignore them indeed.

> A new language will naturally have a much smaller pool of experienced developers. For any middle to large company that's a huge problem. The more developers there are available for a company, the better they like it.

That's also true, e. g. look how few developers use D. I think the only way to change this is to make the language SIMPLE, EASY but also efficient at the same time. Like python. Though python is not aiming to be a replacement of C, so it does not count - but people are quite easily able to learn and use it. C is much harder to use; just give new recruits a task to implement things that manipulate memory and pointers a lot.

> The C ABI is the standard for interoperability

Any language can have that too so I don't see this as a problem.

> 1. Better syntax

> Having a "better syntax" than C is mostly subjective.

Wrong. And this is what 99% of those "I will replace C with my language XYZ" get wrong. The syntax they use usually SUCKS. They think syntax matters absolutely not at all. They are wrong. But they think they are right, so they write a useless pile of crap and then wonder why nobody writes in that language.

> 2. Safer than C > Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

This is partially correct, partially wrong. Rust showed that safety is a feature; C++ agreed. C does not. I understand the speed penalty, and I am not saying you need to make safety a pseudo-religion like Rust did, but that trade-off needs to be determinable by the code author. So, some code can be fast like in C; for other code the trade-off may be different. A language should make it super-easy to distinguish here. Rust does not make it super-easy. C even less.

> Programmer productivity

> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed.

Also totally wrong. Yes, writing code is not always the bottle neck, but what he forgets is the simplicity of writing good, fast code. If it takes 5 hours to write 3 lines of code, something is wrong with the language itself.

by shevy-java

8/21/2026 at 12:03:24 PM

> that a language that would be able to replace C, needs to target both the speed issue without compromise AND the efficiency of writing code,

C++ tried this. You can use null-terminated char arrays like in C, or you can use std::string and it works like Python or Ruby. C++'s problem is that by having so many features to please everyone, the interactions between some of the features are less than obvious, and there's always some feature you're encountering for the first time.

by inigyou

8/21/2026 at 10:43:42 AM

[dead]

by TechLatestnet

8/21/2026 at 10:31:01 AM

[dead]

by WhereIsTheTruth