I like the pragmatic approach to backwards compatibility (accepting relatively rare breakage that's not too hard to fix) instead of requiring 100% compatibility without exceptions
Thankfully Rust is compiled so this break is at compile time, and seems simple to fix. I wonder if their could even be an auto fix for it.
My software gets done.
The idea that it would suddenly not be done because the compiler upgraded sounds like a potentially limitless amount of future work. Why would I want to invest in something that promises that?
Rust's edition system gives you the best of both worlds, with caveats. Some changes will be impossible.
Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.
It’s better to plan for this in advance and use a stack where upgrades are done gracefully, rather than sticking your head in the sand and pretending it doesn’t happen.
Unless you just have an axe to grind?
really says a lot that someone can say this apparently absolutely seriously
Luck is not a process.
Safety critical work / security-sensitive work is completely orthogonal to the rust release cycle.
Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
When I talked with the people at AWS responsible for updating both the myriad Java compilers in use as well as Rust for every project in the company, they claimed that updating Rust was always painless and didn't even appear as a blip in their radars compared to other similarly wide reaching updates.
https://predr.ag/blog/some-rust-breaking-changes-do-not-requ...
"Never add anything" isn't a tenable position, and in practice the breakage hasn't been bad enough to need special treatment yet.
To avoid those problems, you'd have to proactively disambiguate any item with its trait name, which is so un-ergonomic that people genuinely prefer the possibility of occasional breakage.
If your project is truly done, by all means ship it on a N64 cartridge. I can't say I don't have sympathy for that attitude. But don't expect this is how the world works today. And don't forget, N64 cartridges weren't built using massive amounts of dependency, so it was easier to confidently declare something "done".
And when it wakes up, it’s not like this is some massive change. It’s trivial and automatable.
This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
We know how that looks, and it's not good. See Scala and Python.