The Real Problem With Rust is Not "Wokeness" (It Never Was)
To avoid the discussion about Rust getting distorted, diluted, detracted, diverted, derailed, and destroyed by sheer nonsense, let's count some (not all) of the ways in which Rust fails to deliver on its promise.
First, let's revisit what Rust promised, at least unofficially and informally. Funded by Google (the lion's share of its revenue), Mozilla developed Rust for a variety of purposes; the most advertised aspect was, "memory safety" and hence security.
As a C programmer myself (since ages ago), I can relate to the concern about a lack of safety checks when allocating a chunk of memory and dereferencing objects (or equivalent of that). This problem isn't limited to C, which encourages the use of pointers - a concept that I learned in school almost 30 years ago.
What else does Rust promise? Well, not that much really. The "Rust People" (this is how they sometimes refer to themselves) like to talk about aspects such as performance (that means speed, nothing else), but they fail to mention it comes at the expense of other key aspects, such as cross-platform support (including old 32-bit chipsets). In practice, there's also evidence to suggest that in many cases Rust is slower than analogous stuff implemented in C or some other programming languages - some of which have long enjoyed if not relied on mature and well-tested optimisers that Rust lacks*, either runtime accelerators or "off-line" rewriters, set aside compilers (there is no "one C" or "universal C"; C is the language, the compilers that deal with that language produce different binaries and diversity is a strength we must cultivate).
![[Speed Limit Sign] Rust: you can't go faster than this, only one compiler](/i/2025/12/rust-compiler.png)
So let's assume, for argument's sake, that the only compelling reason to rewrite things in Rust or start new projects with Rust is "security".
A black eye for the Rust project has only just become visible, as in Linux - where only a small fraction of the code uses Rust - there was a serious vulnerability tied to Rust. To be clear, a kernel crashing is a very big deal. I am typing this article on a PC that hasn't 'crashed' in 2+ years. Its last reboot was in 2023.
Does Rust reduce reliability? Possibly. Let's not come out with a "verdict" on this, at least not yet.
Then there's the legal "hairball"; Richard Stallman, whenever asked about Rust, typically goes on and on about the trademark, set aside concerns about the licences that many Rust People favour (not copyleft).
So we have legal issues and technical issues with Rust. Set aside the mass censorship, the reliance on (and love of) proprietary Microsoft tools, and Microsoft apologists in charge (we covered this ages ago, long before anyone but us truly criticised Rust).
Sure, there are social aspects that concern us, but we don't need to limit the discussion of Rust to that. If we do, then they'll try to collectively dismiss all critics as "for political reasons", whereupon so-called "Rust People" play the "marginalised minority" card and demonise every single critic, even those who have mentioned legal and technical matters for over 5 years already.
It's OK to focus a lot less on "Rust People" and instead talk about Rust. There's no lack of arguments against Rust as a framework/language/community.
Don't feed the trolls who attack "Rust People" on political grounds. Even if you find what they say to be funny or entertaining, they are a disservice to all Rust critics; they create a misleading caricature of Rust critics.
For a more technical or tech-focused (nothing political) critique of Rust, consider the links below. █
____
* An associate wanted to also link to articles about Rust's poor performance and long compile times, not to mention the ever-changing specs which makes maintenance and durability lacking compared to C.
Here are some relevant articles: