Hi all! I'd like to share my short essay: Rust is perfectly imperfect
It summarizes my views of Rust -- please bear in mind it's very subjective, my goal wasn't to be "fair" in any way. (My professional background is +10 years developing in C++, some Python and assembly for x86 with some ARM Neon and PowerPC experience).
From what I have seen of twitter it is insanely biased and botted. It often artificially props up opinions that aren't actually aligned with reality based on political biases of a 'specific person'.... but in your essay you start with,
My sampling of the real world is performed via X, formerly Twitter. And as of the end of 2025, it appears that Rust is the most hated language ever.
... O.O
EDIT: Funnily enough, they just made their source code for their 'feed' or 'for you' section public just 13 hours ago. It's quite ironic that it is written in Rust... :'D
Option (value or null/nil/none) and Result (value or error). The types come with a couple of methods
a couple
only 48 for Option and 39 for Result (not counting the duplicated copied and cloned).
ofc Option and Result are not special in any language sense, they are just ubiquitous. but that doesn't matter much
that is genuinely hilarious.
more seriously, X is one of the worst places to try to poll the world's feeling on anything, getting dangerously close to 4chan levels.
of course, there are no perfect solutions, but i would advise trying to look for less biased solutions, or just not mentionning that.
The funnier part is that their 'for you'/feed is actually written in rust :'D
I can agree with a lot you have written there but this puzzled me:
From the perspective of language programming theory, Rust added nothing . Literally, there’s nothing new in it. Of course, someone might shout “THE BORROW CHECKER” — but the borrow checker is just more advanced liveness analysis.
That may be true but I have never seen "liveness analysis" or anything like a borrow checker in any compiled to native code language without a garbage collector anywhere before. And I have used all kind of such languages since 1984. Even the most anal language Ada has learned lessons from Rust's borrow checker. Can you point us to other examples?
Memory safety with no GC is the "unique selling point" that first attracted my attention to Rust. That is the single unique feature that caused me not to just ignore Rust as YAFL (Yet Another F...... Language).
Of course I soon found that Rust has a lot of other sweet features as you say in the article.
I think if you are going to use leaves as the image heading a story about Rust they should clearly show a serious case of Rust infection. https://assets-eu-01.kc-usercontent.com/05836e9f-2692-012f-b4fe-e3f22d127fa9/5741d362-afb9-40ac-879f-44f10636cf63/rhs_scn0000454-birch-rust.jpg?fm=jpg&auto=format&w=960&fit=clip
It's deliciously stupid, I would say. The central, core part of it is this:
And the real funny thing is… it's that that phrase is technically correct.
Except it's “technically correct” in the same sense as phrase “James Watt invented nothing of significance and his stupid machine is just a more advanced version of Aeolipile that was known for centuries”.
In both cases incremental improvements cross the threshold that, suddenly, “changes the world”.
In case of James Watt improvement in something that was just a toy, for centuries, started the process of replacement of human labor with power of machines.
In case of Rust “small improvement” in liveness analysis made it possible to write low-level stuff (browsers, OSes, etc) in a memory safe language.
In both cases there was much enthusiasm and lot of hate… because in both cases the change was radical and profound… even if, technically, it was based on a tiny, not too important change.
P.S. And the rest of the article discusses much less relevant things that were actually already present in languages like Haskell or Scala… they are not critical part of the story, surprisingly enough.
i personally don't think it matters that much, but if one uses actual data the at least we have a chance to getting closer to the truth.
looking at the stack overflow survey 2025, we see that the 4 languages with the highest dev retention (i.e. percentile of people who have used it and want to contine to use it) are in order :
rust (72%), Gleam (70%), Elixir (66%) and Zig (64%).
of course it's not perfect, the stack overflow population has its own biases, but they are more likely to be actual programmers than the average twitter user at least.
And it was based on 31k survey result, which is better than one person's feed which is personalized to ceate the most reaction, be it positive or more often negative.
to add on this : of course one should look at as many sources as possible, and i was at first unhappy to base myself solely on stack overflow. so here is jetbrain, the IDE maker :
also putting rust very high in the "developpers want to adopt this next" category
You can find them in Wikipedia: NIL and Hermes, Cyclone, maybe others.
But the critical part wasn't a special kind of achievement that no one ever was adble to do before, but incremental increase in ergonomics that made a memory safe language ergonomic enough to be both suitable for the use in OS kernerl and also to write many other types of commercial software.
Compare to efforts that gave us seL4 or Google Wuffs: sure, these tools gave us something that's “provably safe” and “extra low-level”… but how many developers are crazy enough to write some CLI utility or GUI program with the use of these tools?
Rust is the first language that combined productivity achievable with languages like F#, Haskell or Scala with “safety without tracing GC” — and that change, small as it is from purely scientific POV, threatens to upend the whole world of low-level systems development… of course such language would be both loved and hated: loved by people who embrace it and hated by people whose jobs are threatened by it.
Opening line; not worth commenting on.
From the perspective of language programming theory, Rust added nothing.
That is essentially (but rephrased[1]) the first answer I read to why the language is called Rust.
The language introduces the traits, called in Java as “interfaces”
You fail here by leading with such comparison.
Overall you add nothing to the pool of people with opinions. 
p.s. You might consider getting added to https://this-week-in-rust.org
& adding tls to your hosting.
and too long ago to remember the source. ↩︎
Is there another programming language that has similar enums? Pascal has tagged structures but the payload is not protected. C has unions but, again, the fields are not protected.
Haskell, Ocaml, scala, and F# at least
It was supposed to be protected, actually. Only most popular implementers neglected to implement that “unimportant detail”. And Extended Pascal was supposed to have generics.
Well… what do you expect from the pinnacle of worse is better centerpiece? When B was extended with ALGOL68 features everything that may be thrown out… was thrown out. For how else can you fit the compile in 16KiB (later 64KiB)? But that doesn't mean these things were unknown, back then! They were just considered unimportant… after all if programmer is not stupid s/he wouldn't access things that shouldn't accessed, right?
Rust got, of course, got Rust's “similar enums” directly from from ML… that's half-century ago language.
It's actually true: Rust doesn't include that many “new” things (remember the motto: technology from the past come to save the future from itself), and, ironically enough, while borrow checker is also “only somewhat improved” versions of what other languages had, decades ago (except we talk about very few, rare languages)… but all these other things that fascinate Wojciech Muła so much are implemented in literally hundreds of languages — and way before Rust implemented them.
If “secret of Rust” lies in the standard library. these powerful enums and other things… then why none of the languages changed anything in all these decades?
The answer is obvious: all these goodies were, traditionally, implemented in the tracing-GC based “academic” languages, thus they were “hiding in a plain sight”: they were “very-well-known” for academics, yet, when these things, finally, arrived in systems language people perceived all these things as “new and exciting”.
No, it was borrow checked and precisely borrow checker that enabled the “Rust revolution” — not because all these other things were not important, but because without borrow checker they remained, mostly, in the realms of scientific magazines, and not in hands of practicing software engineers.
Exactly.
It's not clear to me that B was extended with ALGOL68 features. At least I don't get the impression B was given features so as to be more like ALGOL68 as a design goal. Rather what I read of the history is that C was designed to do one job, that being to enable rewriting of Unix from assembler to a high level language so as to make it portable to other architectures. To that end C was based on B and exactly the features in needed to do it's job were added. Those features may well have been inspired by ALGOL of course. Meanwhile ALGOL68 is widely regarded as something of a disaster, a mass of complexity added to ALGOL. Rather like the misadventure evolving C++ from C.
Rust's enums are essentially identical to SML's datatypes. It's so similar that Rust even has the same ambiguity in match that this paper from 1992 complains about in SML's case.
They exist in tons of languages -- I'm sure SML wasn't the first either -- so long as you go outside of the current OOP mainstream.
but the borrow checker is just more advanced liveness analysis
It's not just "analysis". Lifetimes are part of the static type system. Is there another language that has lifetimes in the type system?
Well… Dennis M. Ritchie very explicitly writes: The scheme of type composition adopted by C owes considerable debt to Algol 68, although it did not, perhaps, emerge in a form that Algol’s adherents would approve of. The central notion I captured from Algol was a type structure based on atomic types (including structures), composed into arrays, pointers (references), and functions (procedures). Algol 68’s concept of unions and casts also had an influence that appeared later.
I kinda not sure what more proof may you want…
I wonder why people love to hate C++. AFAICS most major “warts” in C++ were brought into it in the beginning, when the decisions was made to take crippled-yet-popular language and go from there. It was simultaneously brilliant and awful…
All the things that were added later are less awful, then what C had — the only big problem was the decisions to have full compatibility (at lest in the beginning) and thus duplication of pretty much everything.
It have only become a disaster because of minicomputer revolution: ALGOL 68 was perfectly fine evolution for mainframes, but because instead of mainframes people had to, suddenly, deal with crazy limitations of minis… ALGOL 68 was just too big for them and thus have been remembered as a disaster.
Imagine a world where just as Rust was invented people would have switches to Arduinos (and not as target for their code, but as something to run the development environment on!) — Rust would have immediately become “something of a disaster”.
One may even imagine an alternative world where there would be no gigantic half-century gap between ALGOL 68 and Rust… but it's hard to predice what would have happened in that world: no only minis and micros made development of sophisticated languages impossible for decades, they have also made it possible to have not thousands of software developers, but millions… hard to predict what would have happened in a world where languages wouldn't experience a massive degradation at the end of XX century, yet with much smaller number of developers, too.
I don't think we disagree. My point was that the language that became C was not motivated by adopting ALGOL68 features for the sake of acreting features in a game of language catchup but rather inspiration was taken and adapted from others as an when needed. As your quote says: " although it did not, perhaps, emerge in a form that Algol’s adherents would approve of."
Indeed. Way back in the day when I started to hate on C++ I read Bjarne's book: Design and Evolution of C++. In there in convinces you why every misfeature of C++ has to be the way it is. And it all makes perfect sense. It's hard to disagree with any of it. As long as you are sold on the idea that compatibility with C is a primary goal this new language. With that brain washing one tries to live with it for decades after.
What has been added in recent decades may be less awful but they are still awful and that awfulness traces its roots back to the original gaol, maintain compatibility with C.
That is an interesting argument that ALGOL68 failed because all those pesky mini-computer and later micro-computer users did not have the resources of mainframes available. I have never heard that from those who criticise ALGOL68. I don't know, I had a lot of fun with ALGOL68 on an ICL 2960 back in 1976 
Of course, it's also a strong argument that without C compatibility we wouldn't even be complaining about C++ because nobody would have heard of it (presumably under a different name!).
I don't know what the ideal "C with more stuff" language looks like, but I can't believe that C++ is all that close to it. If nothing else, there's got to be a decent way to make a modules-based compilation model work (I last heard C++ modules are still not really in a usable state!?)
