4 ms·

I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compi

I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compilers, make, etc. are really stable, existing Linux source tarballs have a habit of building fine for decades after initial release.

tialaramex 5y ago
In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.
- humanrebar 5y ago
  Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.
  - tialaramex 5y ago
    So, firstly the editions system means it doesn't even matter about crates using a different edition. Remember that await variable in the Rust 1.0 code above? My Rust 2021 code can still talk about that variable, even though it's from a different edition and the word "await" is now a keyword, it just calls that variable r#await meaning "the identifier named await" - which is a bit ugly but gets the job done for interoperability purposes. But also, all previous versions of published crates are kept indefinitely. If Linux wants serde v1.0.240 then that's fine, even if subsequently serde shipped v1.0.241, v1.1.14 and v2.0.1 the repository holds on to everything.
    - humanrebar 5y ago
      It matters if certain drivers require certain toolchains. C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. You're correct that the kernel codebase could pin older versions of crates when it is appropriate, but it's never quite that simple at scale, especially if the kernel pulls in more than a handful of crates.
      - cesarb 5y ago
        > C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. Funny you should mention that. The Linux kernel recently switched from C89 to C11 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50560ce6a0bdab2fc37384c52aa02c7043909d2c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), so only toolchains that support C11 can compile the kernel. Even before that, the minimum version of GCC required to compile the kernel has risen several times. The current minimum is GCC 5.1, so the GCC 4.9 which you could use to compile the kernel one year ago is no longer good enough.
        humanrebar 5y ago
        Good clarification about the move to C11 and GCC 5. But the move is still deliberately done for the kernel codebase as a central decision. It would be different if they dropped support for older compilers because the 'foobar' crate started using a shiny new Rust feature and forced the issue.

tialaramex 5y ago

In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.

humanrebar 5y ago
Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.
- tialaramex 5y ago
  So, firstly the editions system means it doesn't even matter about crates using a different edition. Remember that await variable in the Rust 1.0 code above? My Rust 2021 code can still talk about that variable, even though it's from a different edition and the word "await" is now a keyword, it just calls that variable r#await meaning "the identifier named await" - which is a bit ugly but gets the job done for interoperability purposes. But also, all previous versions of published crates are kept indefinitely. If Linux wants serde v1.0.240 then that's fine, even if subsequently serde shipped v1.0.241, v1.1.14 and v2.0.1 the repository holds on to everything.
  - humanrebar 5y ago
    It matters if certain drivers require certain toolchains. C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. You're correct that the kernel codebase could pin older versions of crates when it is appropriate, but it's never quite that simple at scale, especially if the kernel pulls in more than a handful of crates.
    - cesarb 5y ago
      > C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. Funny you should mention that. The Linux kernel recently switched from C89 to C11 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50560ce6a0bdab2fc37384c52aa02c7043909d2c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), so only toolchains that support C11 can compile the kernel. Even before that, the minimum version of GCC required to compile the kernel has risen several times. The current minimum is GCC 5.1, so the GCC 4.9 which you could use to compile the kernel one year ago is no longer good enough.
      - humanrebar 5y ago
        Good clarification about the move to C11 and GCC 5. But the move is still deliberately done for the kernel codebase as a central decision. It would be different if they dropped support for older compilers because the 'foobar' crate started using a shiny new Rust feature and forced the issue.