A similar problem afflicts other software in Debian stable; Rust is not unique. The reasonable solution is to stop using Debian stable if you want updates.
use std::arch::asm;
fn main() {
unsafe {
asm!(
"syscall",
in("eax") 60,
in("edi") 0,
out("rcx") _,
out("r11") _,
}
}
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.
Edit: Reworded to remove 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.
If you want Debian to curate your compiler version, then use the Debian curated versions of your Rust software for compatibility.
And it's hardly every Rust thread. There are far too many rust threads to even count, let alone comment on.
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.
what? why? someone has to click the approve on the update+build+publish pipeline.. and that's in most repos anyway.
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.
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.
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.
[1]: https://rustconf.com/schedule#how-we-ship-rust-in-opensuse
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.
This is obvious, right? Rust is compiled with what you have on your machine, while Bash is interpreted and so depends on the capabilities on the target machine.
If you want to use your system toolchain, just install your software from there, it will be compatible with the available toolchains, if it's a library, you don't even need the toolchain if its an application. The software is obviously also gonna be "outdated", because that's the point of Debian, stable software that has been well tested with the system.
> This is because Rust devs, for now, are the type that will immediately beginning putting the new code features
There is the concept of MSRV (Minimum Supported Rust Version) that a great fraction of the community follows. You just specify publicly the minimum version that your library supports and enforce it with CI. This is not as good as having an official standard (say, in Cargo.toml), but a lot better than just implicitly depending on what you think is currently available in bash for most users.
> without consideration that it's not available in any OS repository toolchains
Arch's package has been available on the same day in the last Rust's release. We'll probably have 1.63.0 available today or tomorrow.
It’s present now: https://doc.rust-lang.org/cargo/reference/manifest.html#the-...
There will always be some issues with package maintainers using new features without realizing it, and/or forgetting to bump the minimum version. But now that there is a standard for how it should be done, I can submit patches to these projects to fix the problems when I encounter them.
I don't think a tool that receives regular updates should necessarily come from standard OS repos, they should be stable. Perhaps the Rust people could host their own repositories but the fact they don't do it suggests that it's not worth the hassle. This stuff is handed out for free, take it or leave it.
As Rust is open source software, you're free to grab each Rust release, package it up, and offer it as a package on your own repository, or you could probably pay someone to do it for you if you find the right people. I'd much prefer a repository as well, but I accept that the Rust devs don't work for me and I don't pay for any services that would entitle me to such requests.
- Depencency MSRV errors explaining how to downgrade (merged)
- The dependency resolver skipping versions that need newer Rust. To have reasonable errors, this will require the new pubgrub resolver. The main question is opt-in vs opt-out
- Warnings when using functions newer than your MSRV
Among other ideas
Yeah those always seem to crowd my views on conferences, hordes of Bash developers /s
Nitpick: Bash is interpreted, Rust is compiled. The executable rustc produces may well run on a machine that was not updated in the last 15 years.