• kopasz7@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    21
    ·
    1 day ago

    NACK-ing rust at version 8 of the patchset is kind of a dick move. The 7 others were fine before? Ridiculous that Linus didn’t step in in a definitive way.

    • Kissaki@programming.dev
      link
      fedilink
      English
      arrow-up
      5
      ·
      21 hours ago

      Without having looked into it, I find it plausible that it could take several patchsets to come to an assessment of consequences and conclusion. Especially as they happen alongside assessments and discussion. The patchset number may also be largely irrelevant depending on what was changed.

      • bitcrafter@programming.dev
        link
        fedilink
        arrow-up
        9
        ·
        14 hours ago

        There are definitely legitimate situations where that is the case, but I do not think this is one of them. To quote the reason for the rejection (from here):

        I accept that you don’t want to be involved with Rust in the kernel, which is why we offered to maintain the Rust abstraction layer for the DMA coherent allocator as a separate component (which it would be anyways) ourselves.

        Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it’s definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.

        These do not sound like the words of someone who had been on the fence but was finally pushed over to one side by the last patchset in a sequence.