Yes, and some Rust team members are highly critical of this, precisely because it is a hallmark project and produces the impression laid out in the blog post.
Except this time, the cause was something completely different, as noted by matklad elsewhere in this thread. It’s pretty uncool that the blog post author didn’t post the error message up front and gave room for speculation.
I don’t normally like to criticize this way, but this is a bit of a pattern for the author. It might be coming to your attention for the first time here because of the specific context, but I’ve been frustrated more than once by their posts claiming backwards-compatibility issues in things I’m more involved in/attentive to, because they so often don’t include enough detail for someone to dig in and figure out what the cause was.
The only additional detail I could find was from the author’s Twitter thread on the topic:
In this case it looks like something in a Cargo.toml in Firefox wasn’t to the taste of the newer version of Cargo. Presumably it was valid back then but not any more.
The errors seem unrelated to usage of unstable features in Firefox, contrary to what people repeatedly repeat in comments.
The first one, cargo problem, is https://github.com/rust-lang/cargo/pull/8984. This was a breaking bugfix after 4 years of warnings. When depending on a git repo, cargo originally allowed to specify both commit and tag, which is inherently ambiguous.
The second error is some obscure macro expansion failure. It’s hard to tell what’s going on there without checking the code locally.
I quickly checked Cargo and was surprised to find it’s still pre-1.0, i.e. they reserve the right to make breaking changes. Seems like a hole in the Rust stability story.
Cargo binary is versioned the same way as rustc (you can verify it by typing cargo --version). Cargo also provides the same stability guarantees.
The guarantees are described in the end of https://blog.rust-lang.org/2014/10/30/Stability.html. Notably, “fixing bugs” is allowed. This is in contrast to “windows” strategy of being bug compatible forever. Such bug fixes may break code.
In practice, both for rustc and cargo, this depends on how sever is the bug, and how impactful is the fix. Generally, if it is believed that the bug has very little real-world impact (which is estimated via crater), and it has been warned against for several years, an attempt is made to promote the warning to error on nightly. If it doesn’t end up breaking nightly/beta users, the fix is released.
If the fix turns out to be impactful, it is reverted, and waits until edition, or some hideous work-around is put in its place (iirc, there are a couple of if crate_name == “some-crate” in rustc).
Circling back to cargo, cargo also happens to be implemented in stable rust, and its implementation is published to crates.io as a library. The implementation is not a public API, and does not give any stability guarantees. Hence, the cargo crate is not at 1.0. Historically, cargo --version used to print the library version, creating even more confusion than today, but that was fixed long ago.
The comparison to Go is an interesting one considering that Go 1.16 doesn’t build Go 1.15 by default. Ran into this at work recently. I’m still very new to using Go so I don’t understand all of the details but it was surprising and annoying to encounter.
Deno 1.9 had a similar issue too. 1.9 & 1.10 changed how plugins work which broke some packages that used plugins.
Makes me feel like some projects use semantic versioning as a marketing tactic.
If a project (or company) wants to use versioning as a marketing tactic, that’s fine, but don’t make it look or operate like semver. Chrome and Firefox just use increasing integers. Better yet, tie the version number to when it was released so that people can tell how old it is, like Ubuntu and JetBrains.
Apparently firefox has always been using unstable features of rust? https://news.ycombinator.com/item?id=27492520
Yes, and some Rust team members are highly critical of this, precisely because it is a hallmark project and produces the impression laid out in the blog post.
Except this time, the cause was something completely different, as noted by matklad elsewhere in this thread. It’s pretty uncool that the blog post author didn’t post the error message up front and gave room for speculation.
I don’t normally like to criticize this way, but this is a bit of a pattern for the author. It might be coming to your attention for the first time here because of the specific context, but I’ve been frustrated more than once by their posts claiming backwards-compatibility issues in things I’m more involved in/attentive to, because they so often don’t include enough detail for someone to dig in and figure out what the cause was.
You are correct and sorry for falling into that trap!
Is there any link to an actual error? I am curious what exactly broke.
The only additional detail I could find was from the author’s Twitter thread on the topic:
https://twitter.com/thatcks/status/1379506374049140742
Yeah, check the comment section.
Thanks!
The errors seem unrelated to usage of unstable features in Firefox, contrary to what people repeatedly repeat in comments.
The first one, cargo problem, is https://github.com/rust-lang/cargo/pull/8984. This was a breaking bugfix after 4 years of warnings. When depending on a git repo, cargo originally allowed to specify both commit and tag, which is inherently ambiguous.
The second error is some obscure macro expansion failure. It’s hard to tell what’s going on there without checking the code locally.
I quickly checked Cargo and was surprised to find it’s still pre-1.0, i.e. they reserve the right to make breaking changes. Seems like a hole in the Rust stability story.
This is not correct.
Cargo binary is versioned the same way as rustc (you can verify it by typing
cargo --version). Cargo also provides the same stability guarantees.The guarantees are described in the end of https://blog.rust-lang.org/2014/10/30/Stability.html. Notably, “fixing bugs” is allowed. This is in contrast to “windows” strategy of being bug compatible forever. Such bug fixes may break code.
In practice, both for rustc and cargo, this depends on how sever is the bug, and how impactful is the fix. Generally, if it is believed that the bug has very little real-world impact (which is estimated via crater), and it has been warned against for several years, an attempt is made to promote the warning to error on nightly. If it doesn’t end up breaking nightly/beta users, the fix is released.
If the fix turns out to be impactful, it is reverted, and waits until edition, or some hideous work-around is put in its place (iirc, there are a couple of
if crate_name == “some-crate”in rustc).Circling back to cargo, cargo also happens to be implemented in stable rust, and its implementation is published to crates.io as a library. The implementation is not a public API, and does not give any stability guarantees. Hence, the cargo crate is not at 1.0. Historically,
cargo --versionused to print the library version, creating even more confusion than today, but that was fixed long ago.The comparison to Go is an interesting one considering that Go 1.16 doesn’t build Go 1.15 by default. Ran into this at work recently. I’m still very new to using Go so I don’t understand all of the details but it was surprising and annoying to encounter.
Deno 1.9 had a similar issue too. 1.9 & 1.10 changed how plugins work which broke some packages that used plugins.
Makes me feel like some projects use semantic versioning as a marketing tactic.
Fixed it for you :)
I wonder if someone’s studied the psychology behind version numbers from the user/consumer side.
If a project (or company) wants to use versioning as a marketing tactic, that’s fine, but don’t make it look or operate like semver. Chrome and Firefox just use increasing integers. Better yet, tie the version number to when it was released so that people can tell how old it is, like Ubuntu and JetBrains.