9 ms·

When people on HN claim that the Rust team does not break code that worked in previous language versions, they are not citing that RFC, they are using the term

When people on HN claim that the Rust team does not break code that worked in previous language versions, they are not citing that RFC, they are using the term “breaking change” in its usual plain English meaning. I think it is not just an issue of semantics: there is actually a widespread popular belief that the Rust project guarantees no breaking changes except to fix bugs, which is simply not true. Perhaps the Rust team itself is careful not to actually claim this, in which I retract my assertion that they have done so. But it’s certainly something that is heavily implied as a selling point of the language.

burntsushi 4y ago
Both things can be true. It can be true that we (the Rust team, I am on libs-api) are careful about what we claim while the "plain English" version of it is also true. I explained the mitigation measures we take, and it is quite good at telling us whether a change is going to break people, even if it is strictly acceptable from our API evolution policy. I'm not trying to make a just a dumb semantic point here. We really do take the literal notion of breaking change seriously too. The last time I myself experienced a breaking change was maybe 5 or 6 years ago. Neither ripgrep 0.2.0 nor 0.3.0 compile on current Rust. Although neither of the breaking changes came from library APIs.