Well this seems extremely misleading. Technically this is true: Rust doesn't have forward compatibility.

But it does have guaranteed backwards compatibility since the 1.0 in 2015, which is far more important. So "break things" really doesn't apply. It's trivial to incorporate old code last written in 2015 into brand-new projects.

And nowadays I'm not even seeing too many brand-new language features come out. GATs will land soon, but that really feels like filling out a part of the language that people would have expected to be there anyway.

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.

This is pretty silly.

I mean -- this happens, but this happens to any language, because as others have noted: forwards compatibility isn't a thing. New features will be added, and, given the track record of Rust, these new features have been pretty good!

I recently experienced this relatively trivial issue -- I had only tested some software with the latest stable Rust version, 1.62. A user reported it was not building on the Ubuntu default installed 1.59, and I decided building on that version of Ubuntu was worth it. The fix? Install and use the relevant rust toolchain `rustup default 1.59`, `cargo check` points out exactly the issue (BTW the language change was a good change!), fix and push. It was so easy.

That seems more like “move fast, add things”. I’m not sure how one could sensibly expect a compiler to be able to compile language features from the future.

I tried rust 4 years ago, and it was the case on a great extent. Is it really still true?

You're getting flak for this, but you have a point.

I wouldn't say it changes very fast. If you look at the language features in the past two releases they're all of the form "allow {existing feature} to do {thing you'd expect to be allowed}", and the library additions are minor.

But it changes often, every six weeks, where e.g. Python releases features only once a year. And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up. That means software starts depending on new features in minor frivolous ways that nevertheless break the build for older Rust versions.

I make an effort to have my libraries support older Rust releases, but I have to go out of my way to check for compatibility. Not everybody does that, and it's unrealistic to expect everyone to—but with a different release schedule that would give fewer issues.

I have a policy that is to support at most three releases back.

Requiring upgrades to support new software is normal. New APIs are released, new features that allow for simpler code or remove unneeded unsafe blocks. These are good things.

People don’t need to install the latest software. If they want to install the latest software, then they will need to install the dependencies that support that software. That can be operating system versions, compiler versions, or other library dependencies.

I really don’t understand this mentality of wanting to update one piece of software, but also not wanting to update any other software it might depend on.

> And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up.

That's the problem. It's not the release schedule that's the problem. The answer I've arrived at, right now, is to make the default version of the Ubuntu LTS release immediately prior to the latest, my default.

Is that arbitrary? Yes. Might that change if some very cool Rust features are included in 1.64 -- like, if let chains? Yeah. So should the Rust community perhaps develop best practices on MSRV, at the very least notifying if a package deviates from MSRV norms? Maybe. Is this a big problem? Let's be real -- no, not really.

What you'd expect, and what I think we see, is that over time the new features are less "must have" and so fewer programmers will chase the latest version.

There's quite a gap between "Now arrays implement IntoIterator" (about a year ago, you can e.g. write for loops over an array) and "Termination is now stable" (May 2022, you can have custom exit code handling in your program)

I'm sure a few people were excited about Termination, but practically everybody uses IntoIterator and arrays. So of course they would want that feature.

As a Linux user I remember manually compiling 1.3.x back when odd numbered micro meant "Unstable" because 1.2 didn't have features I really cared about. Today I just run whatever kernel the OS installed. Are there important new Linux features in linux-next? Probably, maybe I will read about them in LWN and look forward to them, I'm definitely not going to bother compiling it by hand for any new feature I can imagine.

This also touches on a really important point -- all this takes place in a context. What is the context? One context -- sometimes there are exciting new features! Another context -- this issue is mostly about users who want to build your software from source (this isn't a problem for you, as such), but who don't want to download a new copy of the compiler to do that. Is this a large group of users, if you're not a library? I don't think so.

What are some examples?