7 ms·

OK, I'll say it because nobody else seems to want to: the sensible approach would be to ask for some help on one of the several official avenues that are open t

OK, I'll say it because nobody else seems to want to: the sensible approach would be to ask for some help on one of the several official avenues that are open to you: users.rust-lang.org to begin with, and then the Discord (if you're comfortable with Discord). Aside from the high quality of help available to anyone, of any proficiency level, there's a pretty good chance you can describe your problem to someone who worked on Rust in Firefox. But why bother with that when you can write passive-aggressive blog posts that are devoid of useful information about the errors that were encountered instead.

xyproto 5y ago
Rust+cargo not being as backward compatible as expected is different to the author wanting to solve one specific problem.
- vlang1dot0 5y ago
  Firefox has explicitly used unstable Rust features for years. Their build system opts into this behavior knowing these features are not guaranteed to be stable in future versions. It's 100% unsurprising that using unstable features means your code might break with a future compiler.
- nextaccountic 5y ago
  The backwards compatibility guarantee of Rust applies only to stable releases. Firefox is weird in that it is enabling nightly features in an unnoficial compiler build that, for some odd reason, they want to tag as "stable". But it isn't.
  - gpm 5y ago
    Technically I believe that they're using the official compiler build, just using an unsupported and undocumented backdoor to enable nightly features in that official stable build.
deleted 5y ago
[deleted]
coldtea 5y ago
What good "high quality of help available to anyone" would be, when the problem is a broken compatibility promise? You don't even have to be affecred by it on any of your programs to want to point it out and criticize it...
- gpm 5y ago
  Well, it would be nice to start with verifying whether or not a compatibility promise was actually broken... as it stands we don't really have enough information to know (short of spending time trying to reproduce OPs build environment ourselves), but as you can see by the comments here the general evidence points towards not.
- z0ltan 5y ago
  Agreed.
- saati 5y ago
  There is no broken compatibility promise here, it used unstable rust, there is no promise of compatibility there. This whole post is a hatchet job.
- TheCoelacanth 5y ago
  They haven't substantiated the claim that the backwards compatibility promise was broken. Rust does not claim perfect backwards compatibility. For instance, unstable features have no backwards compatibility promise.
ferdowsi 5y ago
Needing to jump on a tech support chat server to a debug a language backwards compatibility issue seems another bug, not a feature.
- NieDzejkob 5y ago
  So you're claiming that needing help to fix an issue in a language you don't at all know is bad? How is it supposed to work otherwise? In my opinion, the fact that you have an option of asking an expert in this situation is a good thing.
  - ferdowsi 5y ago
    I don't want my tools to break from under me, and I don't want to be forced to call tech support needlessly. Do you love dealing with refrigerator repairs? Why should we love dealing with Rust repairs?
    - zxzax 5y ago
      It's not needless if you've found an actual bug, i.e. if your refrigerator is actually broken. I too wish it was possible to get a refrigerator that never breaks or malfunctions or needs to be replaced. If you know how to make one of those, please start selling it, you'll probably get very rich.
      - ferdowsi 5y ago
        Experiencing backwards compatibility breakages is not "finding a bug" it is the tool being broken from under you. I don't have to prepare for the possibility of having live tech support open whenever I update the Go binary in my projects. Rust advocates should not try to suggest this is reasonable.
        ChrisSD 5y ago
        If you use highly unstable, nightly only, Rust features then experiencing breakage is almost a certainty. That's why they're highly unstable, nightly only, features.
geofft 5y ago
Interesting that this is basically the same point as a comment on another submission last week from the same blog: https://news.ycombinator.com/item?id=27386666 https://news.ycombinator.com/item?id=27386666 > But they never made this complaint in the actual Bugzilla where someone could consider their feedback, they skipped straight to the "complain via blog post" phase. [...] My advice to the author is that perhaps they should extend a little more charity and "just ask" first, before they jump at the opportunity to complain in public - without having mentioned the issue to anyone with the ability to fix it. Which comment links in turn to another post, for which the blogger writes, > I would file a bug report but I cannot imagine that Fedora would accept it. They already know that this feature doesn't work; it's right there in the DKMS manpage. It's there anyway because, well, I don't know. This is the most user-hostile decision I think I've ever seen Fedora make. but in fact the issue was fixed within a week of reporting it. Firefox, in particular, uses the not-so-secret escape switch to unlock Rust nightly features on Rust stable. A bunch of folks on the Rust team are pretty unhappy about this (see e.g. https://github.com/rust-lang/cargo/issues/6627 https://github.com/rust-lang/cargo/issues/6627), but it is the current situation. So "Firefox broke after I ran rustup" is a very different complaint from "My code, on Rust stable, without the secret escape switch broke after I ran rustup," and the blame (if there is any blame at all, which is unclear without the actual error report) is on the Firefox developers, not the Rust developers. In the general case, the Rust folks care a lot about backwards compatibility, but in turn they do that with an eye towards never having a Rust 2.0. They've taken a lot of innovative steps towards making Rust 1.x usable indefinitely, including the nightly/unstable system, the epoch system, crater, etc. A consequence of staying on Rust 1.x indefinitely is that you cannot possibly be bug-for-bug compatible with Rust 1.0 and Cargo 1.0 for all theoretically possible code (see Hyrum's Law: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/). However, if something breaks in the real world, report it, and I expect the Rust developers will be sympathetic and try to fix it. Without any indication of what broke, nobody can do anything with this post except get unactionably mad at other people, and that's pretty useless for actually getting things done. The author is, of course, free to blog whatever he likes. But I think the HN community should stop upvoting his clickbait posts.
deleted 5y ago
[deleted]
faitswulff 5y ago
The only additional detail I could find 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. https://twitter.com/thatcks/status/1379506374049140742 https://twitter.com/thatcks/status/1379506374049140742
- lamontcg 5y ago
  > wasn't to the taste of i am immediately annoyed by the author using this rhetorical flourish
- twic 5y ago
  Sounds like if this really is a failure of backwards compatibility, it is a failure of such for Cargo, not Rust. Does Cargo have the same backward compatibility goals as Rust itself?
  - steveklabnik 5y ago
    It generally does, yes. Without more details, it is really hard to say what actually happened. I'm not aware of any breaking changes to the Cargo.toml format, though maybe I missed something. They may have also meant "a new dependency version broke", not literally that Cargo couldn't understand Cargo.toml. Need more details.
crazypython 5y ago
The same is true for Dlang. Go on D's IRC channel and you can talk to core compiler authors who will help you find a solution to any problem in ~10 minutes.
izacus 5y ago
My experience with this "high quality help" was usually bunch of less experienced people telling me how I'm doing things wrong and how Rust cannot possible lack a feature or need improvement. And that was after making triple sure that my conversation would not be combative or try to sound entitled. Sadly there is some cult around the whole community... although I find the core developers to be pretty great.

xyproto 5y ago

Rust+cargo not being as backward compatible as expected is different to the author wanting to solve one specific problem.

vlang1dot0 5y ago
Firefox has explicitly used unstable Rust features for years. Their build system opts into this behavior knowing these features are not guaranteed to be stable in future versions. It's 100% unsurprising that using unstable features means your code might break with a future compiler.
nextaccountic 5y ago
The backwards compatibility guarantee of Rust applies only to stable releases. Firefox is weird in that it is enabling nightly features in an unnoficial compiler build that, for some odd reason, they want to tag as "stable". But it isn't.
- gpm 5y ago
  Technically I believe that they're using the official compiler build, just using an unsupported and undocumented backdoor to enable nightly features in that official stable build.

deleted 5y ago

[deleted]

coldtea 5y ago

What good "high quality of help available to anyone" would be, when the problem is a broken compatibility promise? You don't even have to be affecred by it on any of your programs to want to point it out and criticize it...

gpm 5y ago
Well, it would be nice to start with verifying whether or not a compatibility promise was actually broken... as it stands we don't really have enough information to know (short of spending time trying to reproduce OPs build environment ourselves), but as you can see by the comments here the general evidence points towards not.
z0ltan 5y ago
Agreed.
saati 5y ago
There is no broken compatibility promise here, it used unstable rust, there is no promise of compatibility there. This whole post is a hatchet job.
TheCoelacanth 5y ago
They haven't substantiated the claim that the backwards compatibility promise was broken. Rust does not claim perfect backwards compatibility. For instance, unstable features have no backwards compatibility promise.

ferdowsi 5y ago

Needing to jump on a tech support chat server to a debug a language backwards compatibility issue seems another bug, not a feature.

NieDzejkob 5y ago
So you're claiming that needing help to fix an issue in a language you don't at all know is bad? How is it supposed to work otherwise? In my opinion, the fact that you have an option of asking an expert in this situation is a good thing.
- ferdowsi 5y ago
  I don't want my tools to break from under me, and I don't want to be forced to call tech support needlessly. Do you love dealing with refrigerator repairs? Why should we love dealing with Rust repairs?
  - zxzax 5y ago
    It's not needless if you've found an actual bug, i.e. if your refrigerator is actually broken. I too wish it was possible to get a refrigerator that never breaks or malfunctions or needs to be replaced. If you know how to make one of those, please start selling it, you'll probably get very rich.
    - ferdowsi 5y ago
      Experiencing backwards compatibility breakages is not "finding a bug" it is the tool being broken from under you. I don't have to prepare for the possibility of having live tech support open whenever I update the Go binary in my projects. Rust advocates should not try to suggest this is reasonable.
      - ChrisSD 5y ago
        If you use highly unstable, nightly only, Rust features then experiencing breakage is almost a certainty. That's why they're highly unstable, nightly only, features.

geofft 5y ago

Interesting that this is basically the same point as a comment on another submission last week from the same blog: https://news.ycombinator.com/item?id=27386666 https://news.ycombinator.com/item?id=27386666 > But they never made this complaint in the actual Bugzilla where someone could consider their feedback, they skipped straight to the "complain via blog post" phase. [...] My advice to the author is that perhaps they should extend a little more charity and "just ask" first, before they jump at the opportunity to complain in public - without having mentioned the issue to anyone with the ability to fix it. Which comment links in turn to another post, for which the blogger writes, > I would file a bug report but I cannot imagine that Fedora would accept it. They already know that this feature doesn't work; it's right there in the DKMS manpage. It's there anyway because, well, I don't know. This is the most user-hostile decision I think I've ever seen Fedora make. but in fact the issue was fixed within a week of reporting it. Firefox, in particular, uses the not-so-secret escape switch to unlock Rust nightly features on Rust stable. A bunch of folks on the Rust team are pretty unhappy about this (see e.g. https://github.com/rust-lang/cargo/issues/6627 https://github.com/rust-lang/cargo/issues/6627), but it is the current situation. So "Firefox broke after I ran rustup" is a very different complaint from "My code, on Rust stable, without the secret escape switch broke after I ran rustup," and the blame (if there is any blame at all, which is unclear without the actual error report) is on the Firefox developers, not the Rust developers. In the general case, the Rust folks care a lot about backwards compatibility, but in turn they do that with an eye towards never having a Rust 2.0. They've taken a lot of innovative steps towards making Rust 1.x usable indefinitely, including the nightly/unstable system, the epoch system, crater, etc. A consequence of staying on Rust 1.x indefinitely is that you cannot possibly be bug-for-bug compatible with Rust 1.0 and Cargo 1.0 for all theoretically possible code (see Hyrum's Law: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/). However, if something breaks in the real world, report it, and I expect the Rust developers will be sympathetic and try to fix it. Without any indication of what broke, nobody can do anything with this post except get unactionably mad at other people, and that's pretty useless for actually getting things done. The author is, of course, free to blog whatever he likes. But I think the HN community should stop upvoting his clickbait posts.

deleted 5y ago

[deleted]

faitswulff 5y ago

The only additional detail I could find 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. https://twitter.com/thatcks/status/1379506374049140742 https://twitter.com/thatcks/status/1379506374049140742

lamontcg 5y ago
> wasn't to the taste of i am immediately annoyed by the author using this rhetorical flourish
twic 5y ago
Sounds like if this really is a failure of backwards compatibility, it is a failure of such for Cargo, not Rust. Does Cargo have the same backward compatibility goals as Rust itself?
- steveklabnik 5y ago
  It generally does, yes. Without more details, it is really hard to say what actually happened. I'm not aware of any breaking changes to the Cargo.toml format, though maybe I missed something. They may have also meant "a new dependency version broke", not literally that Cargo couldn't understand Cargo.toml. Need more details.

crazypython 5y ago

The same is true for Dlang. Go on D's IRC channel and you can talk to core compiler authors who will help you find a solution to any problem in ~10 minutes.

izacus 5y ago

My experience with this "high quality help" was usually bunch of less experienced people telling me how I'm doing things wrong and how Rust cannot possible lack a feature or need improvement. And that was after making triple sure that my conversation would not be combative or try to sound entitled. Sadly there is some cult around the whole community... although I find the core developers to be pretty great.