I heard they use the entire 'crates' repository as test-cases for breaking changes. If that's accurate, the backwards-compatibility is commendable.

Forward-compatibility is near-impossible. Obviously it'd help if new code didn't use new features, but .. then why add them? How mature does a feature need to be before it's permitted to use them? How does a feature become mature if no-one's allowed to use it? etc.

> How mature does a feature need to be before it's permitted to use them?

Each project has its own answer for that question; the acronym for it is MSRV (Minimum Supported Rust Version), and there's a field in the Cargo.toml for it ("rust-version"). It's not unusual to have the CI test the project with both the MSRV and the latest stable Rust version, to catch accidental use of new features. Unfortunately, there's as of yet no consensus on how to choose the MSRV. Some projects are more conservative ("the MSRV has to be at least one year old", "the MSRV is whatever comes with the oldest still supported LTS of Linux distros X and Y", "I set the MSRV once in the past and don't intend to increase it ever"), some projects are more aggressive ("we support only latest Rust and the previous one"), other projects are somewhere in the middle.

(Edit: there's at the moment a very interesting discussion about the MSRV of the "libc" crate, which a lot of other crates depend on, and MSRV in general, at https://github.com/rust-lang/libs-team/issues/72)

Backwards compatibility is guaranteed afaik, the rare breaking changes are activated by setting a newer Rust "edition" in the project's config. So in theory you can just keep coding Rust 1.0 style if you remove an auto-generated line that's used to set the project to the current 2021 edition.

Rust also tests all public rust code on github

It isn't so much about Rust the language which would be fine if people wrote Rust code like they write, say, Bash code. Bash also gets new features that don't work in older Bash versions. But the Bash mentality means supporting all machines and not using new bash features till you can expect every machine to have it.

The Rust mentality is to use all new features immediately without consideration. And this is entirely on the Rust devs which are, naturally, for now, the bleeding edge types.

Misleading? No. This is the reality of most Rust dev behavior. But you're right in spirit, the problems aren't intrinsic to the Rust language itself.

Yes, it's more-or-less the case that you need the current Rust compiler if you want to compile a bunch of Rust projects and have no issues. But there's really no downside to this. Just grab the latest Rust version. It's free and has no breaking changes.

The only time I can see it being an issue is if you're trying to use the Debian/Ubuntu version of rustc or cargo. The version of rustc on Debian stable is 1.48, which was released in Nov 2020. I'm not sure what advantage there is to shipping such an old version of rustc when it guarantees backward compatibility, but if this is what you have then, sure, a big chunk of the Rust ecosystem won't compile.

---

I still think your original comment was misleading because you said the Rust mentality was "move fast, break things". This almost always refers to a lack of backward compatibility, when existing software no longer works with newer versions of the thing that changed.