4 ms·

I am excited for the future of rust, but I am worried about where the language is today. It is simply a young, unstable language. There are lots of features you

I am excited for the future of rust, but I am worried about where the language is today. It is simply a young, unstable language. There are lots of features you need the nightly compiler for, and there are large breaking changes with every edition every few years. This is fine for many use cases, but not for the Linux Kernel IMO.

biorach 4y ago
> It is simply a young correct > unstable incorrect > There are lots of features you need the nightly compiler for inaccurate There are lots of features that are currently nightly-only. you may or may not need these depending on what you are doing. In particular kernel development does require quite a few nightly-only features, but there is no reason to think that all of these won't make it into stable rust in due course. > and there are large breaking changes with every edition every few years totally incorrect
- randallsquared 4y ago
  > inaccurate ...but then you go on to agree?
  - samus 4y ago
    > there is no reason to think that all of these won't make it into stable rust in due course.
- dahfizz 4y ago
  I feel like you agree with me. All these things that the kernel needs from rust will slowly be stabilized over the next few years. The features will land in future editions of rust. Upgrading to those new editions will involve breaking changes.
  - biorach 4y ago
    Yes, but there is no rush to migrate to the new edition - once stabilised the new features will continue to exist in nightly, in the same form as in stable. And yes, presumably at some stage there will be a migration of the kernel from nightly to stable. There may be breaking changes. This will be a one time thing, and, (based on the current difference between nightly and stable and rate of change) not much more of a hurdle than changing C editions or gcc versions. See my other comment.
  - steveklabnik 4y ago
    > The features will land in future editions of rust. Features land in all editions unless they specifically would be backwards incompatible otherwise.
sanxiyn 4y ago
Editions do not make breaking changes. In fact that is the entire point of editions.
- dahfizz 4y ago
  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
School-Cotton 4y ago
At work we don’t use the nightly compiler and never have. It’s quite rare that this bothers us. If you need an unstabilized feature, there is almost always a crate that emulates it.

biorach 4y ago

> It is simply a young correct > unstable incorrect > There are lots of features you need the nightly compiler for inaccurate There are lots of features that are currently nightly-only. you may or may not need these depending on what you are doing. In particular kernel development does require quite a few nightly-only features, but there is no reason to think that all of these won't make it into stable rust in due course. > and there are large breaking changes with every edition every few years totally incorrect

randallsquared 4y ago
> inaccurate ...but then you go on to agree?
- samus 4y ago
  > there is no reason to think that all of these won't make it into stable rust in due course.
dahfizz 4y ago
I feel like you agree with me. All these things that the kernel needs from rust will slowly be stabilized over the next few years. The features will land in future editions of rust. Upgrading to those new editions will involve breaking changes.
- biorach 4y ago
  Yes, but there is no rush to migrate to the new edition - once stabilised the new features will continue to exist in nightly, in the same form as in stable. And yes, presumably at some stage there will be a migration of the kernel from nightly to stable. There may be breaking changes. This will be a one time thing, and, (based on the current difference between nightly and stable and rate of change) not much more of a hurdle than changing C editions or gcc versions. See my other comment.
- steveklabnik 4y ago
  > The features will land in future editions of rust. Features land in all editions unless they specifically would be backwards incompatible otherwise.

sanxiyn 4y ago

Editions do not make breaking changes. In fact that is the entire point of editions.

dahfizz 4y ago
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

School-Cotton 4y ago

At work we don’t use the nightly compiler and never have. It’s quite rare that this bothers us. If you need an unstabilized feature, there is almost always a crate that emulates it.