Hacker News Reader

Comment by jrvidal | Hacker News Reader

I think we're mixing 2 things here: language backward-compatibility, vs. standard practices about what semver means for Rust libraries. The former is way stronger than the latter.

View on HN

> language backward-compatibility, vs. standard practices about what semver means

I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...

I assume that they mean that you can use Rust as a language without its standard library. This matters here since the Kernel does not use Rust's standard library as far as I know (only the core module).

I'm not aware of semver breakage in the language.

Another important aspect is that Semver is a social contract, not a mechanical guarantee. The Semver spec dedicates a lot of place to clarify that it's about documented APIs and behaviors, not all visible behavior. Rust has a page where it documents its guarantees for libraries [0].

[0] https://doc.rust-lang.org/cargo/reference/semver.html

> Another important aspect is that Semver is a social contract, not a mechanical guarantee for.

Although there are mechanical aids for it: https://crates.io/crates/cargo-semver-checks

The failure mentioned above wasnt a case of the language changing behaviour, but rather the addition of a trait impl in the standard library conflicting with a trait impl in a third party crate, causing the build breakage.

The Rust compiler/language has no notion of semver. Saying "Rust is unstable b/c semver blah blah" is a tad imprecise. Semver only matters in the context of judging API changes of a certain library (crate).

> The only reason to do semantic versioning is compatibility

Sure. But "compatibility" needs to be defined precisely. The definition used by the Rust crate ecosystem might be slightly looser than others, but I think it's disingenuous to pretend that other ecosystems don't have footnotes on what "breaking change" means.

> But "compatibility" needs to be defined precisely.

Compatibility is defined precisely! You're definition requires scare quotes. You want to define it "Precisely" so that you can permit incompatible behavior. No one who cares about compatibility does that, it's just an excuse.

Look, other languages do this differently. Those of use using C99 booleans know we need to include a separate header to avoid colliding with the use of "bool" in pre-existing code, etc... And it sort of sucks, but it's a solved problem. I can build K&R code from 1979 on clang. Rust ignored the issue, steamrollered legacy code, and tried to sweep it under the rug with nonsense like this.

The fundamental issue here is that any kind of inference can have issues on the edges. If you write code using fully qualified paths all the time, then this semver footgun can never occur.

I think you are trying very hard to disagree on basic stuff that works very similarly across different language ecosystems, and (looking at other responses) that you're very angry. Disengaging.

I'll point out again that C, the poster child for ancient language technology, has been able to evolve its syntax and feature set with attention to not breaking legacy code. Excusing the lack of such attention via linguistic trickery about "defining compatibility precisely" does indeed kinda irk me. And disengaging doesn't win the argument.

Reply on news.ycombinator.com