> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line.

Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain.

I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard.

I would much rather go through the easy process of switching to an older Rust tool chain to build something than all of the games we played to keep entire VMs archived with a snapshot of a vendor tool chain that worked to build something.

Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.

> Rust is evolving far too fast

I'm curious why I've seen this sentiment repeated in so many places, I learned Rust once 5 years ago and I haven't had to learn any new idioms and there have been no backwards incompatible changes to it that required migrating any of my code.

The code won't magically stop running because the Rust community continued evolving the language. The old toolchains will be available if there's a compatibility change.

Where's the problem exactly?

Aren't there companies that still use C89 for their production systems? I don't know any in particular but I have read comments here on HN implying that. Just do the same for Rust. Stick to the one major version you started with instead of trying to update the toolchain regularly.

Rust is stable. If you don’t plan on changing crates, newer compilers will compile your 5yo code.

I'm curious what the concern is with the rust editions mechanics in place. Each crate gets to define the language edition it is compiled with. Even if dependencies up convert to later editions they can still be linked against by crates that are an older edition.

As for the broader crate ecosystem, if crates you depend on drop support for APIs you depend on, that could cause you to get stuck on older unsupported releases. Though that is no different of a problem than any other language.

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line.

That statement deserves support.

Can you point at any piece of code from 5 years ago that doesn't work today?

Wait, are you implying that code written in Rust somehow "rusts"?

Isn't that (part of) the purpose of using something like Ariel OS, to isolate you from changes?

Rust is evolving too fast? Rust is evolving EXTREMELY slowly. I dare say even slower than C++ or Python.

I think that was true maybe 5-10 years ago.

We have Rust code in a living code base that is more than 5 years old and it's required maybe one touch in the last 5 years to fix some issues due to stricter rules. It was simple enough it could have been automated.

Are you implying Rust will stop working or something?

Rust is much more stable than C in my experience. Try compiling a decade old C code and see how that goes...