4 ms·
> 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 do
by 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").
- steveklabnik 5y agoI am not saying that there is no possible sample bias from the survey, but it is the best data that we have. I'm not aware of it being an issue for our users in general. Some folks do say things about this from time to time, but it seems like largely hobbyists and open source folks with strong opinions, rather than large corporate users or even most open source users. > As a user running `cargo update` should be enough and the versions increase. They would not increase, because that would be a major version change. To do that, you'd have to go into your Cargo.toml and change the version number there. This would also be true of all of your dependencies. Major versions, while Rust can have two of many of them in tree (but notably, not ones that wrap C libraries, for example...) can still work, but like, then you have two copies until the long tail of your dependencies updates, and maybe by the time that happens, it's bumped again in your code. > So this is a critique because I do actually care about this I totally believe this! It's also possible that I am not right, just my take on what you're saying, that's all :)