3 ms·

Maybe I should have been more specific. Yes, you can stay on an old edition forever and not experience any of the breaking changes. But there are features that

Maybe I should have been more specific. Yes, you can stay on an old edition forever and not experience any of the breaking changes. But there are features that the kernel needs that rust does not support yet, such as a fallible allocation API. These features will trickle in over the next few years. In order to use them, all of the kernel's rust code will have to jump versions and deal with the breaking changes.

biorach 4y ago
The kernel already does something similar every few years by upgrading to a new edition of C or version of gcc. https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ https://lwn.net/Articles/855095/ https://lwn.net/Articles/855095/ This happens rarely and is not considered especially burdensome. Currently it is believed that Rust editions would be handled similarly and be no more burdensome.
- dahfizz 4y ago
  The kernel absolutely does not do this "every few years". Linux was written from day 1 in "ANSI C", which is C89 (Edit - it was actually C89 with GNU extensions. Thanks for the corrections). Only now, after 30 years of development, are they considering moving to C99, which is itself over 20 years old.
  - sanxiyn 4y ago
    > Linux was written in ANSI C This is laughably untrue. If it were so, ClangBuiltLinux project would have been trivial, but it was anything but. Linux was written from day 1 in GCC C, and it still is.
  - cesarb 4y ago
    > Linux was written from day 1 in "ANSI C", which is C89. Actually, Linux was written from day 1 in the GCC dialect of C (that is, "gnu89"), using GCC extensions without worry. Compiling the kernel with clang only became possible after clang implemented nearly all GCC extensions the kernel used.
  - biorach 4y ago
    I said > upgrading to a new edition of C OR version of gcc the latter absolutely does happen every few years. Maybe I shouldn't have lumped the C thing in with it, but whatever.
    - dahfizz 4y ago
      Sure, but bumping the minimum version of a compiler is a way different thing than taking in a new version of a language. Rust will involve a lot of the later, which is bad for the kernel IMO.
      - biorach 4y ago
        Rust puts out a new edition every 3 years or so. The list of backwards incompatibilities in the 2021 edition was pretty small. I don't think that there will be a need to migrate language versions all that often, and, based on what I've seen of how Rust handles backwards compatibility, I don't think it will be an especially big leap.
        sanxiyn 4y ago
        I would normally agree with this, but Rust for Linux project in fact uses lots of unstable Rust features, and unstable Rust features in fact break a lot (as they should). Unstable Rust is in fact more painful than GCC C, so pain of upgrade is a genuine con against Rust. I just think benefit is larger.
        biorach 4y ago
        Which raises an interesting question... Will changes to interfaces in nightly be handled similarly to how internal kernel API changes are handled? - i.e. if your code is in-tree then the mantainers of the Rust integration will update your code to ensure compatibility with the new nightly interface.
      - skitter 4y ago
        You don't need to switch editions, new language feature generally are available in old editions too. For example, generic associated types, which came out two weeks ago, work fine in edition 2015.
- murderfs 4y ago
  > by upgrading to a new edition of C It's done that once, in 30 years.
  - biorach 4y ago
    replied to in another sub-thread
proto_lambda 4y ago
Incorrect. Library features like the fallible allocation API are available to all editions, for better or worse - it also means you can't make breaking changes to the standard library ever, not even with a new edition. New language features may require a new edition, though the vast majority of them don't - here's the list of all the changes in Edition 2021 (a new one is released every 3 years): https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html

biorach 4y ago

The kernel already does something similar every few years by upgrading to a new edition of C or version of gcc. https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ https://lwn.net/Articles/855095/ https://lwn.net/Articles/855095/ This happens rarely and is not considered especially burdensome. Currently it is believed that Rust editions would be handled similarly and be no more burdensome.

dahfizz 4y ago
The kernel absolutely does not do this "every few years". Linux was written from day 1 in "ANSI C", which is C89 (Edit - it was actually C89 with GNU extensions. Thanks for the corrections). Only now, after 30 years of development, are they considering moving to C99, which is itself over 20 years old.
- sanxiyn 4y ago
  > Linux was written in ANSI C This is laughably untrue. If it were so, ClangBuiltLinux project would have been trivial, but it was anything but. Linux was written from day 1 in GCC C, and it still is.
- cesarb 4y ago
  > Linux was written from day 1 in "ANSI C", which is C89. Actually, Linux was written from day 1 in the GCC dialect of C (that is, "gnu89"), using GCC extensions without worry. Compiling the kernel with clang only became possible after clang implemented nearly all GCC extensions the kernel used.
- biorach 4y ago
  I said > upgrading to a new edition of C OR version of gcc the latter absolutely does happen every few years. Maybe I shouldn't have lumped the C thing in with it, but whatever.
  - dahfizz 4y ago
    Sure, but bumping the minimum version of a compiler is a way different thing than taking in a new version of a language. Rust will involve a lot of the later, which is bad for the kernel IMO.
    - biorach 4y ago
      Rust puts out a new edition every 3 years or so. The list of backwards incompatibilities in the 2021 edition was pretty small. I don't think that there will be a need to migrate language versions all that often, and, based on what I've seen of how Rust handles backwards compatibility, I don't think it will be an especially big leap.
      - sanxiyn 4y ago
        I would normally agree with this, but Rust for Linux project in fact uses lots of unstable Rust features, and unstable Rust features in fact break a lot (as they should). Unstable Rust is in fact more painful than GCC C, so pain of upgrade is a genuine con against Rust. I just think benefit is larger.
        biorach 4y ago
        Which raises an interesting question... Will changes to interfaces in nightly be handled similarly to how internal kernel API changes are handled? - i.e. if your code is in-tree then the mantainers of the Rust integration will update your code to ensure compatibility with the new nightly interface.
    - skitter 4y ago
      You don't need to switch editions, new language feature generally are available in old editions too. For example, generic associated types, which came out two weeks ago, work fine in edition 2015.
murderfs 4y ago
> by upgrading to a new edition of C It's done that once, in 30 years.
- biorach 4y ago
  replied to in another sub-thread

proto_lambda 4y ago

Incorrect. Library features like the fallible allocation API are available to all editions, for better or worse - it also means you can't make breaking changes to the standard library ever, not even with a new edition. New language features may require a new edition, though the vast majority of them don't - here's the list of all the changes in Edition 2021 (a new one is released every 3 years): https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html