[ronsor]

> As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed.

Most toolchains don't have as much churn as Rust.

[vlovich123]

Disagree. No stable release of Debian today supports c++23 which is coming up on two years old at this point (this corresponds to a major Rust edition, not the minor stuff they publish on an ongoing basis every month).

Java in Bookworm installs JDK 17 which is three years old at this point. Java itself is on 23 with 21 being an LTS release.

This means that upstream users intentionally maintain an old toolchain just to support Debian packaging or maintain their own deb repo with newer tools.

You’re confusing cause and effect. People aren’t migrating because Debian packaging lags so badly, not because there aren’t improvements projects would love to otherwise use.

[0x457]

> Most toolchains don't have as much churn as Rust.

What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code.

Now compare rust releases to this: https://gcc.gnu.org/releases.html

[vlovich123]

Rust’s release cadence is 6 weeks not 6 months.

[0x457]

My bad, I thought it was 6 months. Okay, a bit too often, but no reason why debian folk can't update it more often than it is now.

[umanwizard]

> latest rustc always able to compile older rust code.

That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.

[vlovich123]

I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.

[umanwizard]

It is correct. For example, this code (admittedly a contrived example, just to illustrate the point) compiles in 1.82 but not in 1.83:

  trait OptionExt {
      fn get_or_insert_default();
  }
  
  impl<T> OptionExt for Option<T> {
      fn get_or_insert_default() {}
  }
  
  fn main() {
      Option::<()>::get_or_insert_default();
  }

The reason is that `get_or_insert_default` was added to the stdlib in 1.83, and takes a different number of arguments, so it clashes with the user-defined one here.

[0x457]

Interesting, I would think that having OptionExt in scope would make it clear which method to use.