7 ms·

Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways s

Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev. And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.

jcranmer 4y ago
> Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.
- superkuh 4y ago
  I installed Debian 11 before it was released officially. Its rustc was less than 3 months old. I personally ran into 2 rust programs I couldn't compile due to compiler forwards incompatibility within weeks. One example was the software defined radio program, plotsweep, if you want to look it up in cargo.
  - nicoburns 4y ago
    That's an application, not a library though. There's really no reason for an application not to require the latest compiler version if they so choose. There are definitely libraries that take this approach too, but they tend to be higher-level domain-specific ones. The foundational libraries in the ecosystem tend to take a much more conservative approach to MSRV (minimum supported rust version), supporting older Rust versions for as long as possible, and only bumping the version when new features that significantly improve the library are released (and often only once the versions implementing those features are packaged in stable releases of major distros). For example, the `rand` crate supports Rust versions down to 1.36 (released in July 2019) [0], the regex crate supports down to 1.41.1 (released Feb 2020) [1], etc. [0]: https://github.com/rust-random/rand#rust-version-requirements https://github.com/rust-random/rand#rust-version-requirement... [1]: https://github.com/rust-lang/regex#minimum-rust-version-policy https://github.com/rust-lang/regex#minimum-rust-version-poli...
    - superkuh 4y ago
      You're saying no true Scotsman will require the latest rust compiler. I'm saying that's not how it is for non-Rust developers trying to use things written in Rust.
      - nicoburns 4y ago
        I'm saying the really core libraries (the only ones the linux kernel would ever consider using) don't suffer from this problem. If your development environment is permissive enough that you can pick up a wider variety of libraries, then I can't see any reason not to use the latest compiler.
        superkuh 4y ago
        So we agree. Programs written in Rust don't last more than a couple months. It's just the core libraries that are decent. Btw, I just attempted to install another rust program (legdur), and guess what, my rustc is too out of date to handle it ("failed to parse the `edition` key, this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions"). So that's 3 of 4 attempts to run Rust programs that have failed. Granted, my rustc is now about a year old, but that's still absurdly short.
        zRedShift 4y ago
        > legdur First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca1181518277672e7f71bc3551efd1d3de1fc19c https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815... Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler? Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected. You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV). You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo. I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch https://github.com/itmettkeDE/cargo-patch. Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.
- devmor 4y ago
  That's because you're not specifically using programs built with brand new rust features and then complaining that you have to update the compiler to use them. You know, like a sane person.
- gspr 4y ago
  > Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler. Oh hey, there's two of us ;-) My shoulders relaxed significantly when I also put Cargo in offline mode, pointed it to the directory where Debian installs its librust-*-dev packages, and stopped downloading rapidly changing stuff off of crates.io.
cmrdporcupine 4y ago
Alternatively the sheer weight of the Linux kernel's influence means that the GCC implementation of Rust becomes the dominant one, altering the way people install and manage Rust. Rust is good, but I also do not like the trend in every language and/or build system having its own package management with its own third party dependencies and its own custom installers separate from the distro. I understand the pragmatic problems this solves, but I think it has serious ramifications for reproducibility, security, auditing, etc.
- ImprobableTruth 4y ago
  The reproducibility story with system package managers is an absolute nightmare. In general, language package management systems, containerization and fully statically linked distributions (appimage, flatpak, snaps, etc.) are all a direct response to system package managers being woefully inadequate in all sorts of ways. And unless something like Nix takes over which actually allows reproducible builds, we'll continue to see alternative solutions continue to encroach on system package managers.
  - cmrdporcupine 4y ago
    Absolutely, I understand why these systems are there. And see the issue. The problem is the rapid propagation of them. There's too many, and they live outside the purvey of the distribution management, and often (... NPM, etc.) have poor auditing and moderation. I see why they happen. I don't blame the people to make them. I just think it's a potentially awkward situation when it comes to something as core as the kernel; which has traditionally only required GCC.
    - jupp0r 4y ago
      Rapid propagation? Fully statically linked binaries have been a thing for decades. The practice only got broken under most Linux distros when glibc decided to make it impossible to be linked against statically.
    - SubjectToChange 4y ago
jjice 4y ago
> it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Feels like a pretty blanket statement. I'd assume that they'd base the minimum version on Rust's editions. An edition is released every 3 years and is meant to be a solid LTS (as far as I'm aware) version of the language. If they use Rust 2021 edition, you can tell the compiler that (like C89 vs C11) and it will reject code that's newer. C has plenty of newer stuff too that isn't allowed in kernel code at the moment as well.
- pornel 4y ago
  Rust editions are nothing like C versions. They're orthogonal to language version. They're more like C trigraphs or -W flags. All new Rust features are available from all Rust editions. The 2015 edition has got new features 3 weeks ago, and will get more again in 3 weeks. Old Rust editions are only for backwards compatibility with old source code, e.g. to let it use names that became keywords later.
- Rusky 4y ago
  Editions aren't that clear-cut- crates targeting old editions can still use most new language features, and all new library features. For example, the NLL borrow checker was originally enabled in the 2018 edition, but it's now available in 2015 as well. Editions are more designed to manage backwards-incompatible changes, like new keywords or tweaks to corner cases in the type system.
jeroenhd 4y ago
Rust has language versions and you can specify the language version to use in your Cargo.toml file. This is possible today and it shouldn't pose a problem for the kernel at all as long as there are rules about what versions to support. You don't need a super modern version of the spec to use Rust. As for Rust's incompatibilities, as long as you stay clear from methods marked unstable and the nightly compiler versions you'll be fine. Rust's libraries have breaking changes, but the stable language features haven't had any since the 1.0 release as far as I'm aware. If your problem is forwards compatibility, well, you can't use clang10 to compile the kernel either. Sometimes the version gets bumped, but it doesn't need to happen too often. I think GCC's rust compiler will keep up just fine.
- vips7L 4y ago
  Half of the ecosystem depends on the nightly compiler.
  - wongarsu 4y ago
    That used to be true a couple years ago, but I don't think I've used a nightly compiler version at any point in the last 12 months. That said, I think for this first phase the kernel is planning on a specific stable version of the compiler with nightly features enabled, because they have a couple specific needs that haven't made it through the stabilization process yet.
  - smolder 4y ago
    I dont't think "half" is accurate, at least not anymore. A lot of things have moved from Nightly to Stable compatibility with stabilization of async, for example. Rocket builds on stable now, while for a long time it didn't. I'd like to see the actual percentage but AFAIK it would take some analysis. Crates.io shows 86417 total crates, searching for "stable" shows 3346 and "nightly" shows 2527... So that's not a good heuristic, probably.
    - rdsubhas 4y ago
      Parent is saying the proportion is very high. It's not the exact number that matters. Even if one dependency your project uses needs nightly, then your entire project has to use nightly.
noobermin 4y ago
Sympathetic, but isn't Linux like the poster child for demanding vendors and whoever maintain drivers and stuff without just leaving it working for months to years? Rust is just more bleeding edge than Linux then (which might be a substantial difference, I don't know).
raxxorraxor 4y ago
Shouldn't we wait for Rust to be more stable then? I still fear that its restrictions are a bit of a fad. If it is included at one point you will hardly ever get rid of it again.

jcranmer 4y ago

> Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.

superkuh 4y ago
I installed Debian 11 before it was released officially. Its rustc was less than 3 months old. I personally ran into 2 rust programs I couldn't compile due to compiler forwards incompatibility within weeks. One example was the software defined radio program, plotsweep, if you want to look it up in cargo.
- nicoburns 4y ago
  That's an application, not a library though. There's really no reason for an application not to require the latest compiler version if they so choose. There are definitely libraries that take this approach too, but they tend to be higher-level domain-specific ones. The foundational libraries in the ecosystem tend to take a much more conservative approach to MSRV (minimum supported rust version), supporting older Rust versions for as long as possible, and only bumping the version when new features that significantly improve the library are released (and often only once the versions implementing those features are packaged in stable releases of major distros). For example, the `rand` crate supports Rust versions down to 1.36 (released in July 2019) [0], the regex crate supports down to 1.41.1 (released Feb 2020) [1], etc. [0]: https://github.com/rust-random/rand#rust-version-requirements https://github.com/rust-random/rand#rust-version-requirement... [1]: https://github.com/rust-lang/regex#minimum-rust-version-policy https://github.com/rust-lang/regex#minimum-rust-version-poli...
  - superkuh 4y ago
    You're saying no true Scotsman will require the latest rust compiler. I'm saying that's not how it is for non-Rust developers trying to use things written in Rust.
    - nicoburns 4y ago
      I'm saying the really core libraries (the only ones the linux kernel would ever consider using) don't suffer from this problem. If your development environment is permissive enough that you can pick up a wider variety of libraries, then I can't see any reason not to use the latest compiler.
      - superkuh 4y ago
        So we agree. Programs written in Rust don't last more than a couple months. It's just the core libraries that are decent. Btw, I just attempted to install another rust program (legdur), and guess what, my rustc is too out of date to handle it ("failed to parse the `edition` key, this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions"). So that's 3 of 4 attempts to run Rust programs that have failed. Granted, my rustc is now about a year old, but that's still absurdly short.
        zRedShift 4y ago
        > legdur First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca1181518277672e7f71bc3551efd1d3de1fc19c https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815... Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler? Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected. You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV). You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo. I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch https://github.com/itmettkeDE/cargo-patch. Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.
devmor 4y ago
That's because you're not specifically using programs built with brand new rust features and then complaining that you have to update the compiler to use them. You know, like a sane person.
gspr 4y ago
> Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler. Oh hey, there's two of us ;-) My shoulders relaxed significantly when I also put Cargo in offline mode, pointed it to the directory where Debian installs its librust-*-dev packages, and stopped downloading rapidly changing stuff off of crates.io.

cmrdporcupine 4y ago

Alternatively the sheer weight of the Linux kernel's influence means that the GCC implementation of Rust becomes the dominant one, altering the way people install and manage Rust. Rust is good, but I also do not like the trend in every language and/or build system having its own package management with its own third party dependencies and its own custom installers separate from the distro. I understand the pragmatic problems this solves, but I think it has serious ramifications for reproducibility, security, auditing, etc.

ImprobableTruth 4y ago
The reproducibility story with system package managers is an absolute nightmare. In general, language package management systems, containerization and fully statically linked distributions (appimage, flatpak, snaps, etc.) are all a direct response to system package managers being woefully inadequate in all sorts of ways. And unless something like Nix takes over which actually allows reproducible builds, we'll continue to see alternative solutions continue to encroach on system package managers.
- cmrdporcupine 4y ago
  Absolutely, I understand why these systems are there. And see the issue. The problem is the rapid propagation of them. There's too many, and they live outside the purvey of the distribution management, and often (... NPM, etc.) have poor auditing and moderation. I see why they happen. I don't blame the people to make them. I just think it's a potentially awkward situation when it comes to something as core as the kernel; which has traditionally only required GCC.
  - jupp0r 4y ago
    Rapid propagation? Fully statically linked binaries have been a thing for decades. The practice only got broken under most Linux distros when glibc decided to make it impossible to be linked against statically.
  - SubjectToChange 4y ago

jjice 4y ago

> it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Feels like a pretty blanket statement. I'd assume that they'd base the minimum version on Rust's editions. An edition is released every 3 years and is meant to be a solid LTS (as far as I'm aware) version of the language. If they use Rust 2021 edition, you can tell the compiler that (like C89 vs C11) and it will reject code that's newer. C has plenty of newer stuff too that isn't allowed in kernel code at the moment as well.

pornel 4y ago
Rust editions are nothing like C versions. They're orthogonal to language version. They're more like C trigraphs or -W flags. All new Rust features are available from all Rust editions. The 2015 edition has got new features 3 weeks ago, and will get more again in 3 weeks. Old Rust editions are only for backwards compatibility with old source code, e.g. to let it use names that became keywords later.
Rusky 4y ago
Editions aren't that clear-cut- crates targeting old editions can still use most new language features, and all new library features. For example, the NLL borrow checker was originally enabled in the 2018 edition, but it's now available in 2015 as well. Editions are more designed to manage backwards-incompatible changes, like new keywords or tweaks to corner cases in the type system.

jeroenhd 4y ago

Rust has language versions and you can specify the language version to use in your Cargo.toml file. This is possible today and it shouldn't pose a problem for the kernel at all as long as there are rules about what versions to support. You don't need a super modern version of the spec to use Rust. As for Rust's incompatibilities, as long as you stay clear from methods marked unstable and the nightly compiler versions you'll be fine. Rust's libraries have breaking changes, but the stable language features haven't had any since the 1.0 release as far as I'm aware. If your problem is forwards compatibility, well, you can't use clang10 to compile the kernel either. Sometimes the version gets bumped, but it doesn't need to happen too often. I think GCC's rust compiler will keep up just fine.

vips7L 4y ago
Half of the ecosystem depends on the nightly compiler.
- wongarsu 4y ago
  That used to be true a couple years ago, but I don't think I've used a nightly compiler version at any point in the last 12 months. That said, I think for this first phase the kernel is planning on a specific stable version of the compiler with nightly features enabled, because they have a couple specific needs that haven't made it through the stabilization process yet.
- smolder 4y ago
  I dont't think "half" is accurate, at least not anymore. A lot of things have moved from Nightly to Stable compatibility with stabilization of async, for example. Rocket builds on stable now, while for a long time it didn't. I'd like to see the actual percentage but AFAIK it would take some analysis. Crates.io shows 86417 total crates, searching for "stable" shows 3346 and "nightly" shows 2527... So that's not a good heuristic, probably.
  - rdsubhas 4y ago
    Parent is saying the proportion is very high. It's not the exact number that matters. Even if one dependency your project uses needs nightly, then your entire project has to use nightly.

noobermin 4y ago

Sympathetic, but isn't Linux like the poster child for demanding vendors and whoever maintain drivers and stuff without just leaving it working for months to years? Rust is just more bleeding edge than Linux then (which might be a substantial difference, I don't know).

raxxorraxor 4y ago

Shouldn't we wait for Rust to be more stable then? I still fear that its restrictions are a bit of a fad. If it is included at one point you will hardly ever get rid of it again.