alt Hacker News1000x yes. Rust is not a One True Language, there exists no One True Language. Rust made some improvements over previous languages (many of which were ported over from previous languages that demonstrated the value but weren't break out successes) and serendipitously those improvements added up to something that was really significant and unlocked interesting and useful capabilities. I'm never going back to how my workflows were before I learned Rust (though I still write in other languages everyday).
But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
Replies
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change
I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.
Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.
If your LLM can output 10-100x the LOC output, and it's equally good at all languages, and you're not bound to an existing language choice or ecosystem, why not choose Rust?
Rust code will be faster, safer, and easier to ameliorate bugs in.
Rust seems like the best language to serialize business logic to now that LLMs are so good at it.
If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.
I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.
LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.
The weird thing about this is many core Rust people agree that Rust is not the best language that could possibly ever be, even evaluated by the core principles of Rust (that is: no UB, no mutable aliasing, no memory bugs).
And if we move outside of Rust's memory model, some people have raised issues with the inconsistent syntax, and the module-based compilation model which makes compilers inherently slow, as you have to parse the whole module every time.
So there's room for improvement, and people are already working on putting ideas into practice, and some of these people who came from the Rust ecosystem itself.
And if you happen to disagree with Rust's core goals (or just place less emphasis on them), then it's obviously not the perfect language.