Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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 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.
  • > 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

  • Thank you I needed a reason to get out of bed this morning, and rolling on the floor laughing was by far the best!
  • There's plenty of alternatives out there, the downfall you see is imaginary.

    Nice ragebait tentative though.

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

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

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

  • 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

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

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

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

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

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

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

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

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

  • We also have D and Zig and Rust. Or even OCaml or Forth, depending on what you see as essentially about C.
    by eru
  • 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
  • > 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.

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

  • 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?