4 ms·

I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, build

I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.

steveklabnik 6y ago
I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.
- swsieber 6y ago
  To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
- returningfory2 6y ago
  Yes! As a non-Rust example, the Go 1.15 compiler can't compile some Go 1.16 projects because they use the new embed library. The idea in the root comment that it's somehow outrageous that a compiler for version N of a language can't compile versions N+M is ... strange. PS I love your book :)
- ISV_Damocles 6y ago
  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 6y 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 6y 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.
- faitswulff 6y ago
  I know only the slightest fundamentals of compilers in general and Rust’s compiler in particular, but would it be technically possible to ship library dependencies as compiled MIR code to older compilers to maintain forward compatibility?
  - steveklabnik 6y ago
    MIR is not stable, so no. In some world where it was, and stability meant "unchanging" not "adds new features", then yes, in theory, it might be possible. Note that this even doesn't actually solve the parent's problem; they want to use the old compiler to compile the new code, not compile the new code with a new compiler and use that binary as a dependency for their code that's built with the old compiler.
    - faitswulff 6y ago
      Ah, I see. I don’t know where I got the idea that they were trying to use newer dependencies instead of just compiling newer code themselves. Thanks.
      - steveklabnik 6y ago
        I mean, maybe they are, I guess that if you add "we somehow allow for binary packages to be distributed via crates.io" that would remove them needing to compile those dependencies themselves, right now, you do both of those things locally, so I was kind of assuming that was still the case.

I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.

steveklabnik 6y ago

I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.

swsieber 6y ago
To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
returningfory2 6y ago
Yes! As a non-Rust example, the Go 1.15 compiler can't compile some Go 1.16 projects because they use the new embed library. The idea in the root comment that it's somehow outrageous that a compiler for version N of a language can't compile versions N+M is ... strange. PS I love your book :)
ISV_Damocles 6y ago
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 6y 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 6y 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.
faitswulff 6y ago
I know only the slightest fundamentals of compilers in general and Rust’s compiler in particular, but would it be technically possible to ship library dependencies as compiled MIR code to older compilers to maintain forward compatibility?
- steveklabnik 6y ago
  MIR is not stable, so no. In some world where it was, and stability meant "unchanging" not "adds new features", then yes, in theory, it might be possible. Note that this even doesn't actually solve the parent's problem; they want to use the old compiler to compile the new code, not compile the new code with a new compiler and use that binary as a dependency for their code that's built with the old compiler.
  - faitswulff 6y ago
    Ah, I see. I don’t know where I got the idea that they were trying to use newer dependencies instead of just compiling newer code themselves. Thanks.
    - steveklabnik 6y ago
      I mean, maybe they are, I guess that if you add "we somehow allow for binary packages to be distributed via crates.io" that would remove them needing to compile those dependencies themselves, right now, you do both of those things locally, so I was kind of assuming that was still the case.