Do you remember more specifics? I've seen four cases:

- a project with no Cargo.lock, where there have been breaking changes in a dependency that wasn't specific enough in Cargo.toml; fixing this requires some finessing of dependencies but is possible to get the project building without any code changes

- a project with proper dependency tree specified, but where a std change cause inference to break specific older versions of a crate in your tree (time 0.35 comes to mind); this requires similar changes to the above

- a project relies on UB on stable code that should always have been disallowed and since fixed; this is tricky, on a dependency, an updated version will likely exist, on your own project you'd have to either change your code or use the older toolchain, knowing that the code might not be doing what you want it to do (this happened a handful of times pre 1.20)

- an older project, with the proper dependency versions specified, being built on a newer platform; I saw this with someone trying to build a project untouched since 2018 on an ARM Mac: the toolchain for it didn't exist back then, and the macOS specific lib they were using didn't have any knowledge either. Newer versions of the library do, of course, but that required updating a set of libs that would be compatible too.

All of these cases are quite rare. You could encounter all of them at the same time, and that would be annoying, enough to have someone doing it for fun say "fuck it" and drop it. You can also get hit by a lightning.

But between Cargo.lock which should allow your project to build on newer toolchains, and access to all prior toolchains, your project should continue to build forever on the same platform.

Either you used nightly, explicitly non stable, rust instead of the default stable rust; or you used dependencies that have been yanked due to security issues; or you didn't commit your lockfile and implicitly upgrades everything by having to generate a new lockfile because you used a really wide range of compatible versions.

All of these options require you to go out of your way to enable breakage.

You could also be in the super unlucky state of using something that was later proved unsound in std, which is the only case where rust will break your code on stable. (Missused unsafe in std)

I've had issues compiling Python 3.12 on ArchLinux when Python 3.12 -> Python 3.13 happened, and few of important packages broke. So I had to compile older version of gcc and build Python 3.12

So, it can happen in any programming language, and to any large projects.

Rust allows me to handle this easily with rust.toolchain file, so, this concern is kinda overblown imo

> Might have something to do with how Cargo manages dependencies

Build against the lockfile to use the same versions.

Unless they were pulled from upstream, they won’t suddenly stop building against the same compiler version. Rustup makes it easy to switch compiler versions to get back to the same one you used, too.

This is not a Rust issue but an inherent issue with dependencies in all languages. External dependencies rot.

For Rust code for serious industrial use cases or firmwares, it's always best to minimize dependencies as much as possible to avoid this. Making local copies of dependencies is also a thing for certain use cases.