4 ms·

I'm not "furious", but I do think your comment was bad and deserved to be downvoted. You're posting a random opinion with nothing to back it up, which is, to bo

I'm not "furious", but I do think your comment was bad and deserved to be downvoted. You're posting a random opinion with nothing to back it up, which is, to boot, factually wrong. What breaking changes has Rust made "on a whim" ?

awesome_dude 1y ago
All day every day I see "random opinion with nothing to back it up" posts on Hacker News, but are not voted down - discuss.
- baq 1y ago
  Rust users read more xkcd than the average hn poster. Or less. Take your pick.
rustdebacletime 1y ago
> What breaking changes has Rust made "on a whim" ? I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. And it caused some projects, like Nix, a lot of pain. https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference/ https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...
- aw1621107 1y ago
  > I don't know about "on a whim" Probably not the best way to lead, considering that that phrase is the entire root of the disagreement you're chiming in on! > but this isn't far off in regards to breaking compatibility. I think it might be worth elaborating on why you think that change "isn't far off" being made "on a whim". At least to me, "on a whim" implies something about intent (or more specifically, the lack thereof) that the existence of negative downstream impacts says nothing about. If anything, from what I can tell the evidence suggests precisely the opposite - that the breakage wasn't made "on a whim". The change itself [0] doesn't exactly scream "capricious" to me, and the issue was noticed before Rust 1.80.0 released [1]. The libs team discussed said issue before 1.80.0's release [2] and decided (however (un)wisely one may think) that that breakage was acceptable. That there was at least some consideration of the issue basically disqualifies it from being made "on a whim", in my view. [0]: https://github.com/rust-lang/rust/pull/99969 https://github.com/rust-lang/rust/pull/99969 [1]: https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 [2]: https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment...
  - rustdebacletime 1y ago
    Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. If Rust proponents argue like this, what breakage will not be forced upon Rust users in the future? Your post itself reinforces the OP's claim. Edit: Seriously. At this point, it seems clear that the culture around Rust, especially driven by proponents like you, indirectly have a negative effect on both Rust software, and software security & quality overall, as seen by the bug discussed in the OP. Without your kind of post, would Ubuntu have felt less pressured to make technical management decisions that allowed for the above bug?
    - aw1621107 1y ago
      > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. > Your post itself reinforces the OP's claim. Again, I think it might be worth elaborating precisely what you think "on a whim" means. To me (and I would hope anyone else with a reasonable command of English), making a bad decision is not the same thing as making a decision on a whim, and you have provided no reason to believe the described change falls under the latter category instead of the former.
      - rustdebacletime 1y ago
        This new post you have made again reinforces the general notion that, yes, closer to "on a whim" than many like, the Rust community is willing to break backwards compatibility. It reflects extremely poorly on the Rust community in some people's eyes that you and other proponents appear to not only be unwilling to admit the issues, like the above issue that caused some people a lot of pain, but even directly talk around the issues. In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. But for Rust, Rust developers just have to suck it up if rustc breaks backwards compatibility. Like Dtolnay's comment in the Github issue I linked indicates. If and once gccrs gets running, that might change. Though I am beginning to worry, for the specification for Rust gotten from Ferrocene might be both incomplete and basically fake, and that might cause rustc and gccrs to more easily risk becoming separate dialects of Rust, which would be horrible for Rust, and since there should preferably be more viable options in my opinion of systems languages, arguably horrible for the software ecosystem as well. I hope that there are plans for robust ways of preventing dialects of Rust.

awesome_dude 1y ago

All day every day I see "random opinion with nothing to back it up" posts on Hacker News, but are not voted down - discuss.

baq 1y ago
Rust users read more xkcd than the average hn poster. Or less. Take your pick.

rustdebacletime 1y ago

> What breaking changes has Rust made "on a whim" ? I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. And it caused some projects, like Nix, a lot of pain. https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference/ https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...

aw1621107 1y ago
> I don't know about "on a whim" Probably not the best way to lead, considering that that phrase is the entire root of the disagreement you're chiming in on! > but this isn't far off in regards to breaking compatibility. I think it might be worth elaborating on why you think that change "isn't far off" being made "on a whim". At least to me, "on a whim" implies something about intent (or more specifically, the lack thereof) that the existence of negative downstream impacts says nothing about. If anything, from what I can tell the evidence suggests precisely the opposite - that the breakage wasn't made "on a whim". The change itself [0] doesn't exactly scream "capricious" to me, and the issue was noticed before Rust 1.80.0 released [1]. The libs team discussed said issue before 1.80.0's release [2] and decided (however (un)wisely one may think) that that breakage was acceptable. That there was at least some consideration of the issue basically disqualifies it from being made "on a whim", in my view. [0]: https://github.com/rust-lang/rust/pull/99969 https://github.com/rust-lang/rust/pull/99969 [1]: https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 [2]: https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment...
- rustdebacletime 1y ago
  Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. If Rust proponents argue like this, what breakage will not be forced upon Rust users in the future? Your post itself reinforces the OP's claim. Edit: Seriously. At this point, it seems clear that the culture around Rust, especially driven by proponents like you, indirectly have a negative effect on both Rust software, and software security & quality overall, as seen by the bug discussed in the OP. Without your kind of post, would Ubuntu have felt less pressured to make technical management decisions that allowed for the above bug?
  - aw1621107 1y ago
    > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. > Your post itself reinforces the OP's claim. Again, I think it might be worth elaborating precisely what you think "on a whim" means. To me (and I would hope anyone else with a reasonable command of English), making a bad decision is not the same thing as making a decision on a whim, and you have provided no reason to believe the described change falls under the latter category instead of the former.
    - rustdebacletime 1y ago
      This new post you have made again reinforces the general notion that, yes, closer to "on a whim" than many like, the Rust community is willing to break backwards compatibility. It reflects extremely poorly on the Rust community in some people's eyes that you and other proponents appear to not only be unwilling to admit the issues, like the above issue that caused some people a lot of pain, but even directly talk around the issues. In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. But for Rust, Rust developers just have to suck it up if rustc breaks backwards compatibility. Like Dtolnay's comment in the Github issue I linked indicates. If and once gccrs gets running, that might change. Though I am beginning to worry, for the specification for Rust gotten from Ferrocene might be both incomplete and basically fake, and that might cause rustc and gccrs to more easily risk becoming separate dialects of Rust, which would be horrible for Rust, and since there should preferably be more viable options in my opinion of systems languages, arguably horrible for the software ecosystem as well. I hope that there are plans for robust ways of preventing dialects of Rust.