DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
64% Positive
Analyzed from 1255 words in the discussion.
Trending Topics
#language#rust#alternative#zig#features#argument#code#bit#already#modern
Discussion (14 Comments)Read Original on HackerNews
> 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.
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?
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.
But obviously nothing will replace C in the sense that C will cease to exist.
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.
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).
Long-term it almost certainly will. But not in our lifetimes, sure.
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.
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.
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.
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.
Nice ragebait tentative though.