35 ms·

That is not what Steve is claiming. The exact quote is: > > code written 5 years ago will often not compile today. > > citation needed. Yes, there's a f

That is not what Steve is claiming. The exact quote is: > > code written 5 years ago will often not compile today. > > citation needed. Yes, there's a few programs that relied on unsound > things for which this is true, but that's a relatively small part of > the overall amount of code. In other words, there are a small number of packages that were doing things outside the bounds of what the Rust change policy guarantees -- for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. This does not mean that Rust code will "often" not compile. It is possible for Steve (and the public at large!) to know this, because the impact of breaking changes are measured by Crater. The alternative choice, to prevent compiler/stdlib changes from being able to break any valid program, would halt language evolution. We've seen this in languages like C and C++, where the standards bodies make a truly heroic effort to avoid breaking code, but (1) they stop being able to evolve the language, and (2) code breaks anyway because there's always someone who's skirting the edge of permitted extension.

School-Cotton 4y ago
> for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. One of these things is not like the other. Implementing your own traits on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable thing to do. Steve specifically said “unsound”, which means something specific. He didn’t say “doing things outside the bounds of what the Rust change policy guarantees”.
- jmillikin 4y ago
  > One of these things is not like the other. Implementing your own traits > on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable > thing to do. It's possible to do, and there's good reasons to do it, but you have to be extremely careful about either (1) specifying all method calls unambiguously, or (2) extensive testing for dependency upgrades. It's very similar to wildcard imports, because you're no longer in sole control of the local namespace. If you choose to let a dependency inject symbols into your local namespace, and that dependency is the standard library, then you're signing yourself up to have every toolchain upgrade be painful. Think of it as similar to naming C/C++ types with leading underscores. Yes, you could have gotten away with `typedef int _Bool;` for decades, but eventually the standard library will call that bet. > Steve specifically said “unsound”, which means something specific. He > didn’t say “doing things outside the bounds of what the Rust change > policy guarantees”. It seems like you're interpreting "unsound" in a sense similar to "violates type-safety soundness", but I don't think that's what Steve meant and it doesn't seem like a reasonable interpretation.
  - steveklabnik 4y ago
    When I wrote the comment being discussed here, I was thinking of the sibling RFC to the one burntsushi linked above, the one for the language instead of for the library: https://rust-lang.github.io/rfcs/1122-language-semver.html https://rust-lang.github.io/rfcs/1122-language-semver.html > This RFC proposes that minor releases may only contain breaking changes that fix compiler bugs or other type-system issues. Primarily, this means soundness issues where "innocent" code can cause undefined behavior (in the technical sense), but it also covers cases like compiler bugs and tightening up the semantics of "underspecified" parts of the language (more details below). But more importantly, the next paragraph: > However, simply landing all breaking changes immediately could be very disruptive to the ecosystem. Therefore, the RFC also proposes specific measures to mitigate the impact of breaking changes, and some criteria when those measures might be appropriate. This has been invoked before; early on in Rust's life, https://rust-lang.github.io/rfcs/1214-projections-lifetimes-and-wf.html https://rust-lang.github.io/rfcs/1214-projections-lifetimes-... fixed a soundness bug, and as it says > Warnings first, errors later. Although the changes described in this RFC are necessary for soundness (and many of them are straight-up bugfixes), there is some impact on existing code. Therefore the plan is to first issue warnings for a release cycle and then transition to hard errors, so as to ease the migration. While the RFC says "a release cycle," that was optimistic. Version 1.4.0 (2015-10-29) introduced the warnings, but the warnings didn't turn into errors until Version 1.7.0 (2016-03-03). This was intentional breakage that did break programs, for good reason. Those are programs that could have compiled on Rust 1.0 but deliberately do not past 1.7.0. While it is also true that there are tiny things that technically would break code in many releases, these are only allowed because they're very small things that measurably do not have an impact. They're theoretically breaking, or would be breaking in a different universe where people had written different code that relied on it. Or that is considered acceptable via the API evolution RFC. But in practice, those changes just aren't experienced by Rust programmers as "breakage." In the 2021 survey, only 2% of users disagreed with the statement "I can upgrade the stable compiler version without fear of my code failing to compile." That isn't even saying "Did it break your code"; it's talking about how users feel about this. 2%! If you go with the closer question, "Upgrading to a new stable compiler version requires either no changes or extremely small and easy changes to my code," only 1% disagree. The data provided doesn't provide more granularity than a percent, so I don't know how it's rounded. But in terms of "is the Rust Project causing users pain with breaking changes?" the answer is very clearly "no."

School-Cotton 4y ago

> for example unintentionally relying on type-checking bugs, or unstable features accidentally stabilized, or implementing traits on a struct when the library doesn't control both of them. One of these things is not like the other. Implementing your own traits on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable thing to do. Steve specifically said “unsound”, which means something specific. He didn’t say “doing things outside the bounds of what the Rust change policy guarantees”.

jmillikin 4y ago
> One of these things is not like the other. Implementing your own traits > on foreign types isn’t “unsound”, it’s an absolutely normal and reasonable > thing to do. It's possible to do, and there's good reasons to do it, but you have to be extremely careful about either (1) specifying all method calls unambiguously, or (2) extensive testing for dependency upgrades. It's very similar to wildcard imports, because you're no longer in sole control of the local namespace. If you choose to let a dependency inject symbols into your local namespace, and that dependency is the standard library, then you're signing yourself up to have every toolchain upgrade be painful. Think of it as similar to naming C/C++ types with leading underscores. Yes, you could have gotten away with `typedef int _Bool;` for decades, but eventually the standard library will call that bet. > Steve specifically said “unsound”, which means something specific. He > didn’t say “doing things outside the bounds of what the Rust change > policy guarantees”. It seems like you're interpreting "unsound" in a sense similar to "violates type-safety soundness", but I don't think that's what Steve meant and it doesn't seem like a reasonable interpretation.
- steveklabnik 4y ago
  When I wrote the comment being discussed here, I was thinking of the sibling RFC to the one burntsushi linked above, the one for the language instead of for the library: https://rust-lang.github.io/rfcs/1122-language-semver.html https://rust-lang.github.io/rfcs/1122-language-semver.html > This RFC proposes that minor releases may only contain breaking changes that fix compiler bugs or other type-system issues. Primarily, this means soundness issues where "innocent" code can cause undefined behavior (in the technical sense), but it also covers cases like compiler bugs and tightening up the semantics of "underspecified" parts of the language (more details below). But more importantly, the next paragraph: > However, simply landing all breaking changes immediately could be very disruptive to the ecosystem. Therefore, the RFC also proposes specific measures to mitigate the impact of breaking changes, and some criteria when those measures might be appropriate. This has been invoked before; early on in Rust's life, https://rust-lang.github.io/rfcs/1214-projections-lifetimes-and-wf.html https://rust-lang.github.io/rfcs/1214-projections-lifetimes-... fixed a soundness bug, and as it says > Warnings first, errors later. Although the changes described in this RFC are necessary for soundness (and many of them are straight-up bugfixes), there is some impact on existing code. Therefore the plan is to first issue warnings for a release cycle and then transition to hard errors, so as to ease the migration. While the RFC says "a release cycle," that was optimistic. Version 1.4.0 (2015-10-29) introduced the warnings, but the warnings didn't turn into errors until Version 1.7.0 (2016-03-03). This was intentional breakage that did break programs, for good reason. Those are programs that could have compiled on Rust 1.0 but deliberately do not past 1.7.0. While it is also true that there are tiny things that technically would break code in many releases, these are only allowed because they're very small things that measurably do not have an impact. They're theoretically breaking, or would be breaking in a different universe where people had written different code that relied on it. Or that is considered acceptable via the API evolution RFC. But in practice, those changes just aren't experienced by Rust programmers as "breakage." In the 2021 survey, only 2% of users disagreed with the statement "I can upgrade the stable compiler version without fear of my code failing to compile." That isn't even saying "Did it break your code"; it's talking about how users feel about this. 2%! If you go with the closer question, "Upgrading to a new stable compiler version requires either no changes or extremely small and easy changes to my code," only 1% disagree. The data provided doesn't provide more granularity than a percent, so I don't know how it's rounded. But in terms of "is the Rust Project causing users pain with breaking changes?" the answer is very clearly "no."