4 ms·

Distros have historically been very concerned with "real development"! Debian, for example, packages all of the tools and libraries needed to build any package

Distros have historically been very concerned with "real development"! Debian, for example, packages all of the tools and libraries needed to build any package in Debian, so users can easily modify and recompile any package. Because there are a lot of packages in Debian, it's become a great, stable, vetted source for general-purpose compilers and libraries. Rust really is an outlier here -- its marketing has managed to walk a delicate tightrope to be considered "stable" and "mature" enough to use for important projects like Linux, while also still being new and fast-moving enough that it's unreasonable to expect those projects to use anything but the most recent bleeding-edge nightly build. And that will create problems, if only for distros trying to build the kernel binaries that they ship to their users.

rcxdude 2y ago
That's still user-focused. I actively avoid debian as a development distro because things are so out of date and so customised. Arch is a much nicer development experience because they for the most part just take the up-to-date upstream projects and build them without fiddling with a bunch of stuff. (OTOH, if I'm standing up a box to run critical network services, debian is strongly preferable)
duped 2y ago
If I'm writing new software I'm necessarily developing something that's not yet a package in any distro, so I don't necessarily want to be using distro tools to build it. I also strongly disagree with the characterization that it's "easy" to modify and recompile "any" package in a given distro - typically, someone would prefer to modify the upstream and build it (which may not be possible with the distro's supplied tools) and use the modified version. Distributions in my experience are quite bad about shipping software that's "easy" to be modified by users. It's a gross mischaracterization of the ecosystem to suggest that many Rust projects require "bleeding-edge nightly" to build. Kernel modules have a moderate list of unstable features that are required but many (all?) have already been stabilized or on the path to stabilization so you don't need a "bleeding edge" nightly. In my opinion the lagging nature of distros illustrates one of the fundamental problems of relying on them for developing software, but hey, that's an ideological point.
- csande17 2y ago
  > Kernel modules have a moderate list of unstable features that are required but many (all?) have already been stabilized or on the path to stabilization so you don't need a "bleeding edge" nightly. https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2 lists the "unstable features" required by the Rust for Linux codebase. It's a long list! One of the features in the "Required" section was "added as unstable in 1.81", a version released three weeks ago. Presumably that means you need a nightly build that's newer than (or at least close to the release of) Rust 1.81, which seems pretty bleeding-edge to me. I sure hope none of those "paths to stabilization" involve making any changes to the unstable features, because then release versions of the Linux kernel would be stuck pinning random old nightly builds of the Rust compiler. That seems even worse than depending on bleeding-edge ones.

rcxdude 2y ago

That's still user-focused. I actively avoid debian as a development distro because things are so out of date and so customised. Arch is a much nicer development experience because they for the most part just take the up-to-date upstream projects and build them without fiddling with a bunch of stuff. (OTOH, if I'm standing up a box to run critical network services, debian is strongly preferable)

duped 2y ago

If I'm writing new software I'm necessarily developing something that's not yet a package in any distro, so I don't necessarily want to be using distro tools to build it. I also strongly disagree with the characterization that it's "easy" to modify and recompile "any" package in a given distro - typically, someone would prefer to modify the upstream and build it (which may not be possible with the distro's supplied tools) and use the modified version. Distributions in my experience are quite bad about shipping software that's "easy" to be modified by users. It's a gross mischaracterization of the ecosystem to suggest that many Rust projects require "bleeding-edge nightly" to build. Kernel modules have a moderate list of unstable features that are required but many (all?) have already been stabilized or on the path to stabilization so you don't need a "bleeding edge" nightly. In my opinion the lagging nature of distros illustrates one of the fundamental problems of relying on them for developing software, but hey, that's an ideological point.

csande17 2y ago
> Kernel modules have a moderate list of unstable features that are required but many (all?) have already been stabilized or on the path to stabilization so you don't need a "bleeding edge" nightly. https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2 lists the "unstable features" required by the Rust for Linux codebase. It's a long list! One of the features in the "Required" section was "added as unstable in 1.81", a version released three weeks ago. Presumably that means you need a nightly build that's newer than (or at least close to the release of) Rust 1.81, which seems pretty bleeding-edge to me. I sure hope none of those "paths to stabilization" involve making any changes to the unstable features, because then release versions of the Linux kernel would be stuck pinning random old nightly builds of the Rust compiler. That seems even worse than depending on bleeding-edge ones.