BatmanAoD
The animation that goes with this is pretty slick: https://x.com/Phantom_TheGame/status/1748457358521426375?s=20
This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/
One problem with this is that C is in no way the “roots” of programming; it’s older than most of the languages we use today, but Fortran, Lisp, and Cobol are all older and are also still in use. (And of course there are other languages that predate C but have mostly fallen out of use, such as Pascal.) It feels “low-level” because it closely reflects the hardware for which it was originally designed, the PDP-7 and later the PDP-11. But in fact it hasn’t truly been “low-level” for a long time: I highly recommend the ACM article “C Is Not a Low-level Language; Your computer is not a fast PDP-11.”
“I don’t care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one.”
wat
Rust’s 1.0 release (i.e. the date on which the language received any sort of stability guarantee) was in 2015, and this article was written in 2019. Measuring the pace of feature development of a four-year-old language by its release notes, and comparing against a 50-year-old language by counting bullet points in Wikipedia articles, is absolutely ridiculous.
Yes, younger languages adopt features more quickly, and Rust was stabilized in a “minimal viable product” state, with many planned features not yet ready for stabilization. So of course the pace of new features in Rust is high compared to older languages. But Wikipedia articles are in no way comparable to release notes as a measure of feature adoption.
I think C is faster, more powerful, and more elegant.
“More elegant” is a matter of opinion. But “faster” and “more powerful” should be measurable in some way. I’m not aware of any evidence that C is “faster” than Rust, and in fact this would be extremely surprising since they can both be optimized with LLVM, and several of the features Rust has that C doesn’t, such as generics and ubiquitous strict aliasing, tend to improve performance.
“Powerful” can mean many things, but the most useful meaning I’ve encountered is essentially “flexibility of application” : that is, a more powerful language can be used in more niches, such as obscure embedded hardware platforms. It’s really hard to compete with C in this regard, but that’s largely a matter of momentum and historical lock-in: hardware vendors support C because it’s currently the lowest common denominator for all hardware and software. There’s nothing about Rust the language that makes it inappropriate for hardware vendors to support at a low level. Additionally, GCC is probably the toolchain with the broadest hardware support (even hardware vendors that use a bespoke compiler often do so by forking GCC), and Rust currently has two projects (mrustc and gccrs) working to provide a way to use GCC with Rust. So even the advantage C has in terms of hardware support is narrowing.
But note that there are also niches for which C is widely considered less appropriate than Rust! The most obvious example is probably use in a front-end web application. Yes, C should in theory be usable on the front-end using emscripten, but Rust has had decent support for compiling to WebAssembly almost as long as it’s been stabilized.
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.