• WalnutLum@lemmy.ml
    link
    fedilink
    arrow-up
    36
    arrow-down
    3
    ·
    13 hours ago

    The problem is that the Linux kernel is monolithic so introducing rust into it does have certain repercussions about downstream compatibility between modules.

    Right now the rust code in the kernel uses c bindings for some things and there’s a not-insignificant portion of C developers who both refuse to use rust and refuse to take responsibility if the code they write breaks something in the rust bindings.

    If it was pure C there would be no excuse as the standard for Linux development is that you don’t break downstream, but the current zeitgeist is that Rust being a different language means that the current C developers have no responsibility if their code refactoring now breaks the rust code.

    It’s a frankly ridiculous stance to take, considering the long history of Linux being very strict on not breaking downstream code.

    • HumanPenguin@feddit.uk
      link
      fedilink
      English
      arrow-up
      6
      ·
      6 hours ago

      A valid point. But the result is that over a pretty short period of time. These C developers will find delays in how quickly their code gets accepted into stable branches etc. So will be forced to make clear documentation into how the refactoring effects other elements calling the code. Or move on altogether.

      Sorta advantageous to all and a necessary way to proceed when others are using your code.

    • Leaflet@lemmy.world
      link
      fedilink
      English
      arrow-up
      11
      ·
      7 hours ago

      Rust developers are fine with C bindings changing, they just want that to be communicated to them by the C developers before they break.