3 ms·

Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer comp

Rust uses "Editions" (e.g., 2015, 2018, 2021, 2024) to introduce breaking changes without splitting the ecosystem. Every edition remains supported by newer compiler versions _indefinitely_. The only churn is on projects targeting "nightlies" but there's no reason you can't target a stable one for projects that need that stability.

jonathanstrange 6mo ago
That invariably leads to bitrot and low maintainability. It's one among many reasons why I don't use Rust.
- monocasa 6mo ago
  I don't see how that leads to bitrot, or low maintainability.
- orochimaaru 6mo ago
  You have the same issue with C, no? C is upgrading versions, compilers have changed, hardware evolves and somethings in the past aren't supported as well anymore.
  - megous 6mo ago
    Not really. Not in the scale of my C dev life, which has been 20 years so far.
    - fluffybucktsnek 6mo ago
      Neither have we with Rust.
    - orochimaaru 6mo ago
      I did C and C++ till about 2010 or so. The major platform which I did dev for (hp ux) is no longer supported.
elcritch 6mo ago
Unfortunately quite a few useful Rust libraries seem to require nightly. Now I’ve not extensively used Rust but almost everytime I did it ended up needing nightly to use some library or other.
- estebank 6mo ago
  Do you recall which libraries? Use of nightly fell of a cliff after 2018. Looking at the bottom of https://lib.rs/stats#rustc-usage https://lib.rs/stats#rustc-usage, ~8% of all crates.io requests came from a nightly newer than that corresponding to 1.86. That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. The prevalence of nightly is also niche specific. If you're in embedded it is likely you need to use some nightly-only features that haven't been stabilized, but if you have an OS chances are that you don't.
  - SkiFire13 6mo ago
    > That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. To be fair it's not even a lower bound, as using a stable compiler doesn't imply the absence of nightly only feature (as in Cargo features, the ones you can enable on crates you depend on).
    - kibwen 6mo ago
      For the purposes of this discussion the question is not whether or not a crate exposes optional features that require a nightly compiler, but whether or not a crate makes use of the nightly compiler mandatory, which has become extremely rare in my experience. Perhaps it's more common in some embedded use cases, but if people want to make that assertion, I would ask that they either mention which libraries they're specifically talking about or which nightly features they're specifically referring to.
      - estebank 6mo ago
        I think the divide is apps vs libraries: a library that requires their dependants to set an environment variable opting out of stability guarantees is unlikely to gain adoption, but applications that do so are more common, like Firefox.

jonathanstrange 6mo ago

That invariably leads to bitrot and low maintainability. It's one among many reasons why I don't use Rust.

monocasa 6mo ago
I don't see how that leads to bitrot, or low maintainability.
orochimaaru 6mo ago
You have the same issue with C, no? C is upgrading versions, compilers have changed, hardware evolves and somethings in the past aren't supported as well anymore.
- megous 6mo ago
  Not really. Not in the scale of my C dev life, which has been 20 years so far.
  - fluffybucktsnek 6mo ago
    Neither have we with Rust.
  - orochimaaru 6mo ago
    I did C and C++ till about 2010 or so. The major platform which I did dev for (hp ux) is no longer supported.

elcritch 6mo ago

Unfortunately quite a few useful Rust libraries seem to require nightly. Now I’ve not extensively used Rust but almost everytime I did it ended up needing nightly to use some library or other.

estebank 6mo ago
Do you recall which libraries? Use of nightly fell of a cliff after 2018. Looking at the bottom of https://lib.rs/stats#rustc-usage https://lib.rs/stats#rustc-usage, ~8% of all crates.io requests came from a nightly newer than that corresponding to 1.86. That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. The prevalence of nightly is also niche specific. If you're in embedded it is likely you need to use some nightly-only features that haven't been stabilized, but if you have an OS chances are that you don't.
- SkiFire13 6mo ago
  > That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. To be fair it's not even a lower bound, as using a stable compiler doesn't imply the absence of nightly only feature (as in Cargo features, the ones you can enable on crates you depend on).
  - kibwen 6mo ago
    For the purposes of this discussion the question is not whether or not a crate exposes optional features that require a nightly compiler, but whether or not a crate makes use of the nightly compiler mandatory, which has become extremely rare in my experience. Perhaps it's more common in some embedded use cases, but if people want to make that assertion, I would ask that they either mention which libraries they're specifically talking about or which nightly features they're specifically referring to.
    - estebank 6mo ago
      I think the divide is apps vs libraries: a library that requires their dependants to set an environment variable opting out of stability guarantees is unlikely to gain adoption, but applications that do so are more common, like Firefox.