Debian packages rustc-mozilla for building Firefox. Firefox ESR 102 will need Rust 1.59.0, and that version has already been uploaded to stable-proposed-updates. 1.59 is not that old (it's from February 2022), and this actually builds after installing rustc-mozilla (with cargo even):

    use std::arch::asm;
    
    fn main() {
        unsafe {
            asm!(
                "syscall",
                in("eax") 60,
                in("edi") 0,
                out("rcx") _,
                out("r11") _,
        }
    }

I guess for the same reason, there's now an LLVM and Clang 13 build in Debian stable, too.

I'm not entirely happy how Mozilla forced Debian's hand here. But it means that there is a relatively current, Debian-blessed Rust compiler, and you can use it for your own builds if you are willing to upgrade from time to time.

To clarify, without weighing in on the merits of his complaint, what he is saying is that he wants to use Debian Stable's toolchain and is complaining that the ecosystem (crates on cargo.io) move to use the latest features so quickly, and don't have stable backport releases, which makes this difficult to do.

Edit: Reworded to remove disagreement.

I think you're agreeing with me, but framing it as disagreement.

> the ecosystem (crates on cargo.io) move to use the latest features so quickly

They use the new features in new software -- implying he wants to use that new software. If he uses the old versions that predate the new features, this wouldn't be a problem for him.

Yes, I did misread your post, sorry. Reworded mine to be a clarification rather than a contradiction.

I'm not saying now that's opposed.

If you want Debian to curate your compiler version, then use the Debian curated versions of your Rust software for compatibility.

The Debian example you're referring to was back from the release of 11. It's rustc was only 3 months old and already couldn't compile. That's not a "Debian is old" problem and it was only one instance. I've run into the same problem on other OSes as well. No OS hosted repo can keep up with rust and it's particular selection of bleeding edge types.

And it's hardly every Rust thread. There are far too many rust threads to even count, let alone comment on.

> No OS hosted repo can keep up with rust and it's particular selection of bleeding edge types.

Seems empirically false https://archlinux.org/packages/extra/x86_64/rust/

If your distro is unwilling to update a package with a single backwards-compatible minor version bump every 6 weeks, that’s a cultural issue, not a technical one. The “stability“ Debian imagines it gets from shipping a years-old compiler version instead of keeping up-to-date with non-breaking compiler updates is entirely mythical.

Pick a less sclerotic distro next time.

Oh, okay, we'll just write off the entire concept of release based distributions because of one start-up programming language then? Everyone switches to rolling release? That's pretty absurd.

> No OS hosted repo can keep up with rust and it's particular selection of bleeding edge types.

what? why? someone has to click the approve on the update+build+publish pipeline.. and that's in most repos anyway.

It's a problem for any fast moving software, not only Rust. Debian (and Ubuntu which is based on it) is notoriously slow on updating many packages.

Wait can't you just use rustup?

`rustup` is awesome for me as a developer. It is not convenient if I am a sysadmin that wants everything to be stable and consistent: I can not afford to use special version/package manager for every single language. It is fair to complain that rust (or python, or julia, or any other language with built-in environment/package/version manager) do not play nice with OS package managers. OS package managers are starting to take "vendoring" a bit more seriously because of this.

you want stability (aka reproducibility across a fleet of workstations/servers), but also security updates too, right? but what do you mean by consistency?

and you don't want to create & distribute a new OS image for every security update, right?

... anyway, the whole problem is that only upstream can provide these kind of security updates. it's a big (and very very convenient) lie what stable distros are doing, but many times packages have to work their asses off to maintain this illusion. (when they have to patch/backport/hack packages.)

Rust as language and compiler provides the tools for this (stability guarantee, editions, etc), but the various devs that provide Rust crates might not.

sure, if Rust would artificially hold back new features that would definitely provide this "stability", but it's no wonder devs adopt new features fast. because they want them, it makes their life easier, and it usually makes users happier too.

what the Rust ecosystem is doing (and NodeJS and TypeScript and quite a few high-velocity newish ones) is providing updates to users faster.

of course there are some users that might not care about this, hence debian oldstable, and so on.

I get where you're coming from but Rust is a bad example of your point. Its tooling is straightforward to install and use. I've bootstrapped several build and CI/CD servers and Node / Python have been infinitely more troublesome. I only had a problem with Rust once.

The "stable" OS packages are mostly marketing without much substance and while they're convenient for you they also kind of lie to you as well.

I could understand any other languages, but rustup is kind of flawless from my point of view, so I'm still wondering what doesn't work exactly : o

The OS package managers seem to be figuring it out, though. I've noticed that both opensuse and debian have a number of rust programs in their repos.

Debian does it the hard way, by making a Debian package for every crates-io dependency used and patching Rust programs to use Debian's forked deps instead. It's seems like a massive pain for them, and has zero value for Rust end users, since normal Cargo won't use any of this.

Rust often carries its own bugfixes to its LLVM version (before they're accepted upstream). Debian unbundles LLVM from Rust and makes Rust use Debian's LLVM, which creates a risk of undoing Rust's bugfixes and causing miscompilations.

I don't think anyone should be using Debian-packaged Rust. Debian's and Rust's policies are fundamentally incompatible. This results in Debian having a hopelessly outdated inferior package that is a pain for both Debian users and the rest of the Rust ecosystem.

At the most recent RustConf William Brown spoke about how OpenSUSE deals with Rust[1]. If I remember correctly from his talk they started doing something very similar to Debian and then eventually settled on "just use rustup". I wish I had taken better notes because there was more nuance to the history there but I think they'll release the videos of the talks soon.

[1]: https://rustconf.com/schedule#how-we-ship-rust-in-opensuse

We're both talking about the same elephant but we're obviously touching different ends of it. The end I'm touching smells really bad.

The fact that so many distros have to go extremely far out of their way, breaking their standard processes, shows that Rust is unique in it's tomfoolery. You guys are advocating for the tail to wag the dog.

or find ways to override and install latest, for example latest LLVM that would work on debian stable - https://apt.llvm.org/ (maybe similar for rust?). I've switched to this on my debian stable so that I can compile carbonlang (it needs llvm12, debian stable had only llvm11) - with above I've actually got llvm15, and then week ago switched to llvm16 (I can adjust that back to say llvm14 if I want).

I assume the issue here is not getting the Rust toolchain on a developer system, but Rust packages in APT.

Use nix instead then?