3 ms·

Well this seems extremely misleading. Technically this is true: Rust doesn't have forward compatibility. But it does have guaranteed backwards compatibility si

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.

soneil 4y ago
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.
- alpaca128 4y ago
  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.
- cesarb 4y ago
  > 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 https://github.com/rust-lang/libs-team/issues/72)
- DrMeepster 4y ago
  Rust also tests all public rust code on github
superkuh 4y ago
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.
- vlmutolo 4y ago
  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.

soneil 4y ago

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.

alpaca128 4y ago
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.
cesarb 4y ago
> 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 https://github.com/rust-lang/libs-team/issues/72)
DrMeepster 4y ago
Rust also tests all public rust code on github

superkuh 4y ago

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.

vlmutolo 4y ago
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.