[maxbond]

1000x 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?)

[torginus]

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.

[zozbot234]

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

[hu3]

I think Rust has a big flaw to overcome in the age of LLMs: slow compilation.

If they can't fix this, a language with similar guarantees, even syntax, but fast compilation is bound to succeed in niches where Rust is desireable.

Iteration speed is a big bottleneck in agentic workflows. Well, any workflow.

[maxbond]

Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.

[esperent]

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

[tmtvl]

> (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)

Lisp. Which coincidentally solved memory management over a decade before C was created.

I also think ALGOL was more influential than COBOL, but measuring influence can be tricky.

[xlii]

Sir/Madam/Sovereign... did you hear about Prolog? ;)

[maxbond]

This isn't the first time someone has said that to me, so I really ought to make time to learn it.

[echelon]

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.

[resonious]

I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.

[maxbond]

I do choose Rust. For now. I write Rust everyday. I'm generating Rust at this moment.

But when I learn a better language I will adopt it.

[wolvesechoes]

> LLMs emitting Rust feels like building well-engineered steel skyscrapers

Oh the irony.

Good thing that real engineers cannot build their skyscrapes with LLMs.