5 ms·

I am still pretty new to Rust (about a year of usage), but I think there are ways to have this "forward compatibility" problem be a less significant impact in r

I am still pretty new to Rust (about a year of usage), but I think there are ways to have this "forward compatibility" problem be a less significant impact in real world usage, though. Node.js went through similar rapid development of the runtime as Rust is with the compiler. Node's package.json includes an "engine" field to indicate which runtimes are supported from which version, so NPM could immediately tell you if you were trying to use a library for a newer Node version than you have installed, and could automatically downgrade to an older version that still supported your Node version, if one existed. That eliminates much of the pain of using libraries by others that are sticking to the latest release of the language. But it also encouraged library authors to try to push that supported version number down as far as they could, because that would juice adoption of their library in the wild, further making forward compatibility less of an issue. (This isn't exactly apples to apples since most of the advances in Javascript the past decade have been syntactic sugar, not new powerful features, and there is a hard split on async/await versus callbacks as that was more of a feature than just sugar.) In Rust, if libraries could broadcast their minimum Rust version in their crates, and treated changing that as a breaking change (major version bump), and were open to backporting features onto prior majors (for the bigger, important libraries), there can be a rolling drop-off of older versions of Rust instead of hard, unpredictable dropoffs.

swsieber 5y ago
There's an RFC to add the minimum rust version supported. It was merged! The tracking issue is here: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262
steveklabnik 5y ago
I appreciate this post. I have one or two points to make about what you've said here (none of which is wrong) > because that would juice adoption of their library in the wild That requires a lot of people to be using older versions, that is, it assumes there's an audience of people who are interested in using older Rusts. But we don't have that in Rust, even if it was that way with Node. Look at this chart from our survey last year: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r... There isn't a huge audience to get adoption from if you support a wider array of versions; the vast majority of users seem to be using the latest stable. > and treated changing that as a breaking change (major version bump), This is controversial, because in some sense you're not wrong, but this also creates a lot of churn, and churn that doesn't really have to happen. In a model where most folks target the latest stable, you're creating tons of work for most of your users, at the expense of making things slightly better for a very small number of users.
- ISV_Damocles 5y ago
  > That requires a lot of people to be using older versions, that is, it assumes there's an audience of people who are interested in using older Rusts. But we don't have that in Rust, even if it was that way with Node. Look at this chart from our survey last year: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r... So I would cite the classic statistics example of adding armor to the parts of returning aircraft that weren't shot up: https://worldwarwings.com/the-statistics-that-kept-countless-allied-fighter-planes-in-the-sky/ https://worldwarwings.com/the-statistics-that-kept-countless... That survey (that I wasn't aware of despite using Rust) likely self-selects the most enthusiastic users of Rust. There could certainly be a large number of other users, or potential users, that would answer things differently. > This is controversial, because in some sense you're not wrong, but this also creates a lot of churn, and churn that doesn't really have to happen. In a model where most folks target the latest stable, you're creating tons of work for most of your users, at the expense of making things slightly better for a very small number of users. I don't agree that it's that much extra work? As a user running `cargo update` should be enough and the versions increase. If cargo refused to update to a version beyond the currently installed `rustc` version, then this should be completely safe on their end. Then the library authors can either do what they currently do and not backport features/patches for earlier Rust implementations, or they can if they want to support those users (so no extra work is required), but now it's very clear to them (based on download stats on crates.io) how much demand for prior rust compilers there is, and they can decide if they want to provide a stronger backwards compatibility for their library, and the users can tell based on the semver releases for the library if that library supports older versions of `rustc` or no. This is still personally one of my more minor complaints about the Rust ecosystem. It's still far better done than most other major languages, and the current state of Cargo/crates.io was a major factor in our picking Rust over C++ for the project we're using it for. So this is a critique because I do actually care about this and see how it could help both adoption (less worry about "what's the right version of Rust to use?" for newbies) and long-term maintenance (if you can't come to a project a few months later and install any security fixes because there are library changes that require you to upgrade your compiler and there's a cascading set of dependencies-of-dependencies that make that riskier to do, so application-level developers may not want to jump on such a "treadmill").

swsieber 5y ago

There's an RFC to add the minimum rust version supported. It was merged! The tracking issue is here: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262

steveklabnik 5y ago

I appreciate this post. I have one or two points to make about what you've said here (none of which is wrong) > because that would juice adoption of their library in the wild That requires a lot of people to be using older versions, that is, it assumes there's an audience of people who are interested in using older Rusts. But we don't have that in Rust, even if it was that way with Node. Look at this chart from our survey last year: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r... There isn't a huge audience to get adoption from if you support a wider array of versions; the vast majority of users seem to be using the latest stable. > and treated changing that as a breaking change (major version bump), This is controversial, because in some sense you're not wrong, but this also creates a lot of churn, and churn that doesn't really have to happen. In a model where most folks target the latest stable, you're creating tons of work for most of your users, at the expense of making things slightly better for a very small number of users.

ISV_Damocles 5y ago
> That requires a lot of people to be using older versions, that is, it assumes there's an audience of people who are interested in using older Rusts. But we don't have that in Rust, even if it was that way with Node. Look at this chart from our survey last year: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r... So I would cite the classic statistics example of adding armor to the parts of returning aircraft that weren't shot up: https://worldwarwings.com/the-statistics-that-kept-countless-allied-fighter-planes-in-the-sky/ https://worldwarwings.com/the-statistics-that-kept-countless... That survey (that I wasn't aware of despite using Rust) likely self-selects the most enthusiastic users of Rust. There could certainly be a large number of other users, or potential users, that would answer things differently. > This is controversial, because in some sense you're not wrong, but this also creates a lot of churn, and churn that doesn't really have to happen. In a model where most folks target the latest stable, you're creating tons of work for most of your users, at the expense of making things slightly better for a very small number of users. I don't agree that it's that much extra work? As a user running `cargo update` should be enough and the versions increase. If cargo refused to update to a version beyond the currently installed `rustc` version, then this should be completely safe on their end. Then the library authors can either do what they currently do and not backport features/patches for earlier Rust implementations, or they can if they want to support those users (so no extra work is required), but now it's very clear to them (based on download stats on crates.io) how much demand for prior rust compilers there is, and they can decide if they want to provide a stronger backwards compatibility for their library, and the users can tell based on the semver releases for the library if that library supports older versions of `rustc` or no. This is still personally one of my more minor complaints about the Rust ecosystem. It's still far better done than most other major languages, and the current state of Cargo/crates.io was a major factor in our picking Rust over C++ for the project we're using it for. So this is a critique because I do actually care about this and see how it could help both adoption (less worry about "what's the right version of Rust to use?" for newbies) and long-term maintenance (if you can't come to a project a few months later and install any security fixes because there are library changes that require you to upgrade your compiler and there's a cascading set of dependencies-of-dependencies that make that riskier to do, so application-level developers may not want to jump on such a "treadmill").