8 ms·

That's one heck of an extrapolation from one incident, or even one project, in a language that has been post-1.0 for a decade and has a wide variety of users wi

That's one heck of an extrapolation from one incident, or even one project, in a language that has been post-1.0 for a decade and has a wide variety of users with a wide variety of update/upgrade preferences and subcultures.

awesome_dude 1y ago
I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation
- tempest_ 1y ago
  Which makes sense because in 2025 people have grown tired of lack of improvement so that some esoteric ass compiler from the 90s still works or someones 30 year old bash script still functions. Pros and Cons either way for better or worse depending on your perspective.
  - cowsandmilk 1y ago
    That’s an argument against creating uuutils; it is a project that aims for coreutils 100% compatibility. eza, bat, ripgrep, etc are more exciting for at least having different features than coreutils
    - tempest_ 1y ago
      I was more commenting on the Rust community being ready to make breaking changes. Personally while I think Rust is a decent language it would not have caught on with younger devs if C/C++ didn't have such a shitty devex that is stuck 30 years in the past. Younger people will always be more willing to break things and messing around with ancient and unfriendly build/dev does not attract that demographic because why waste time messing around with the build env that actually getting things done. One day rust will be the same and the process will start again.
      - skydhash 1y ago
        If you're on unix, I think the only thing you really need is cc and ld. The build system aims for flexibility instead of each project being its own personal world and things are duplicated ad momentum. Everyone is happy playing in their little sandbox instead of truly collaborating with each other and create great software.
        uecker 1y ago
        Indeed. This is exactly the problem. It is no fun helping with maintenance of an existing project, fix some boring bug, deal with all the historical constraints, necessary support for old systems, etc. It is so much more fun to cargo-download some stuff and build some new shiny Rust-xyz implementation of Z on your Apple Macbook and even get some HN attention just for this. The problem with all the Rust hype is that people convince themselves that they are actually helping the world by being part of a worthwhile cause to rid the world from old languages, while the main effect is that i draws resources away from much more important efforts and places an even higher burden on the ecosystem - making our main problem - sustainable maintenance of free software - even harder.
        zamadatix 1y ago
        I'm not sure a post about a 12 year long project dealing with fixing bugs to match historical constraints with a make build option was really the best choice for this particular rant.
    - zamadatix 1y ago
      It's an argument for/against doing anything. The question is how large of a change can you get away with. Ubuntu seems to think they can get away with a 1:1 replacement being acceptable by 26.04, I doubt they'd think the same about forcing alternative tooling options just because the impetus is the same.
  - cwillu 1y ago
    I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
  - skydhash 1y ago
    Improvement to what? It's not like anyone is creating a new paradigm (or even ripping off an old one, like smalltalk or plan9). It's mostly coming up with a different defaults.
- awesome_dude 1y ago
  As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
  - School-Cotton 1y ago
    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...
- School-Cotton 1y ago
  > Rust still has a very "Ready to make breaking changes on a whim" reputation No it doesn't. What on earth are you talking about?
  - mort96 1y ago
    I like Rust, but almost all libraries I end up using are on some 0.x version...
    - klardotsh 1y ago
      I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning). Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
      - gldrk 1y ago
        That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
    - baq 1y ago
      Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
      - mort96 1y ago
        Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".
ok123456 1y ago
It's been post-1.0 for a decade, but they keep on changing the definition of "nightly." "Stable" lacks too many quality of life features so most things don't target it.
- ViewTrick1002 1y ago
  Rust currently has a problem that too few people are using nightly which makes gathering experience and feedback on new features harder. This is a stark difference to back in the early post 1.0 days where many high profile crates needed nightly and everyone was experimenting.
rustdebacletime 1y ago
A little more than a year ago, breakage. 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-...
- Avamander 1y ago
  Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.
  - rustdebacletime 1y ago
    And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
    - Avamander 1y ago
      Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
      - rustdebacletime 1y ago
        > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
        Avamander 1y ago

awesome_dude 1y ago

I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation

tempest_ 1y ago
Which makes sense because in 2025 people have grown tired of lack of improvement so that some esoteric ass compiler from the 90s still works or someones 30 year old bash script still functions. Pros and Cons either way for better or worse depending on your perspective.
- cowsandmilk 1y ago
  That’s an argument against creating uuutils; it is a project that aims for coreutils 100% compatibility. eza, bat, ripgrep, etc are more exciting for at least having different features than coreutils
  - tempest_ 1y ago
    I was more commenting on the Rust community being ready to make breaking changes. Personally while I think Rust is a decent language it would not have caught on with younger devs if C/C++ didn't have such a shitty devex that is stuck 30 years in the past. Younger people will always be more willing to break things and messing around with ancient and unfriendly build/dev does not attract that demographic because why waste time messing around with the build env that actually getting things done. One day rust will be the same and the process will start again.
    - skydhash 1y ago
      If you're on unix, I think the only thing you really need is cc and ld. The build system aims for flexibility instead of each project being its own personal world and things are duplicated ad momentum. Everyone is happy playing in their little sandbox instead of truly collaborating with each other and create great software.
      - uecker 1y ago
        Indeed. This is exactly the problem. It is no fun helping with maintenance of an existing project, fix some boring bug, deal with all the historical constraints, necessary support for old systems, etc. It is so much more fun to cargo-download some stuff and build some new shiny Rust-xyz implementation of Z on your Apple Macbook and even get some HN attention just for this. The problem with all the Rust hype is that people convince themselves that they are actually helping the world by being part of a worthwhile cause to rid the world from old languages, while the main effect is that i draws resources away from much more important efforts and places an even higher burden on the ecosystem - making our main problem - sustainable maintenance of free software - even harder.
        zamadatix 1y ago
        I'm not sure a post about a 12 year long project dealing with fixing bugs to match historical constraints with a make build option was really the best choice for this particular rant.
  - zamadatix 1y ago
    It's an argument for/against doing anything. The question is how large of a change can you get away with. Ubuntu seems to think they can get away with a 1:1 replacement being acceptable by 26.04, I doubt they'd think the same about forcing alternative tooling options just because the impetus is the same.
- cwillu 1y ago
  I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
- skydhash 1y ago
  Improvement to what? It's not like anyone is creating a new paradigm (or even ripping off an old one, like smalltalk or plan9). It's mostly coming up with a different defaults.
awesome_dude 1y ago
As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
- School-Cotton 1y ago
  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...
School-Cotton 1y ago
> Rust still has a very "Ready to make breaking changes on a whim" reputation No it doesn't. What on earth are you talking about?
- mort96 1y ago
  I like Rust, but almost all libraries I end up using are on some 0.x version...
  - klardotsh 1y ago
    I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning). Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
    - gldrk 1y ago
      That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
  - baq 1y ago
    Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
    - mort96 1y ago
      Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".

ok123456 1y ago

It's been post-1.0 for a decade, but they keep on changing the definition of "nightly." "Stable" lacks too many quality of life features so most things don't target it.

ViewTrick1002 1y ago
Rust currently has a problem that too few people are using nightly which makes gathering experience and feedback on new features harder. This is a stark difference to back in the early post 1.0 days where many high profile crates needed nightly and everyone was experimenting.

rustdebacletime 1y ago

A little more than a year ago, breakage. 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-...

Avamander 1y ago
Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.
- rustdebacletime 1y ago
  And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
  - Avamander 1y ago
    Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
    - rustdebacletime 1y ago
      > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
      - Avamander 1y ago