• azertyfun@sh.itjust.works
    link
    fedilink
    arrow-up
    63
    arrow-down
    5
    ·
    1 month ago

    Don’t force me to deal with your shiny language of the day,

    WE HavE LegItImaTe COnCeRNs

    Exact same shit as last time, some cranky old dude with the territorial instinct of a bulldog sabotages anything to do with rust under a very thin layer of so-called technical concerns, yet refuses to partake in constructive discussion. Like, literally, the changeset is just bindings in rust/kernel? What even is there to complain about regarding maintainability of kernel/dma, given that as far as I can tell the rust devs will deal with any future incompatibilities?

    Very shameful for the kernel community that this kind of aggressive sabotage is regular and seemingly accepted. The incessant toxicity is not a good look and very discouraging to anyone thinking of contributing.

      • devfuuu@lemmy.world
        link
        fedilink
        arrow-up
        10
        ·
        1 month ago

        And they wonder why the rest of the world wants to avoid and run away from that language and culture.

    • jwt@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 month ago

      He might even have legitimate concerns, but this response is just so unconstructive. It’s solely aimed at slighting other programmers.

    • deadcream@sopuli.xyz
      link
      fedilink
      arrow-up
      21
      arrow-down
      1
      ·
      1 month ago

      It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It’s always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I’m not sure if they can keep it up for years and decades in the future.

      Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.

      • burgersc12@mander.xyz
        link
        fedilink
        English
        arrow-up
        12
        ·
        1 month ago

        Yeah, even Linus said he wasn’t 100% sure it was gonna succeed but how else do you know unless you try it.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        It is hard, but what’s the alternative? Does Linux want to be comically insecure forever?

        I know Linus doesn’t really care about security so it’s kind of surprising that he is on board with Rust!

    • henfredemars@infosec.pub
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      1
      ·
      1 month ago

      I’d even have sympathy for this argument that introducing another language is a major undertaking (and it is!) but Linux is already full of lots of other languages (Macros, Makefile, Shell, BPF, assembly languages, Perl, Python scripts…) and developers are willing to do the work to use a language that helps solve problems Linux cares about.

      • deadcream@sopuli.xyz
        link
        fedilink
        arrow-up
        16
        arrow-down
        1
        ·
        1 month ago

        That’s not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don’t affect actual kernel code which is C and assembler language.

        • Corbin@programming.dev
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          1 month ago

          Your argument is completely specious. Re-read that list. Assembly is a second language in the kernel already, and really it’s multiple languages, one per supported ISA. Perl and Python scripts are used to generate data tables; there are multiple build-time languages. eBPF is evaluated at runtime; the kernel contains bytecode loaders, JIT compilers, and capability management for it. The kernel has already paid the initial cost of setting up a chimeric build process which evaluates many different languages at many different stages.

        • henfredemars@infosec.pub
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          1 month ago

          Perhaps not, but if you’re a kernel developer, I believe you are obliged to understand your build system and tooling. The fact of the languages aren’t all used at runtime seems immaterial.

          That said, I am no kernel developer, so take it with a grain of salt.

  • mox@lemmy.sdf.org
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    1 month ago

    And? The GNU General Public License and every project that uses it (including Linux) have also been likened to cancer, as have many other things that impose and spread their conventions/restrictions/requirements when added to larger systems.

    The phrase “going viral” works similarly. These metaphors may not be pretty, but they are not uncommon or inaccurate, either. Stirring up drama around their use doesn’t help the project or the community.

  • 0x0@programming.dev
    link
    fedilink
    arrow-up
    6
    ·
    1 month ago

    “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches,” Ballmer said, back before Linux had metastasized into the Windows Subsystem for Linux.

    Nice writing.

  • laranis@lemmy.zip
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 month ago

    Brain read it as “linked to” and still said, “Yup, that tracks.”

  • Cypher@lemmy.world
    link
    fedilink
    arrow-up
    10
    arrow-down
    12
    ·
    1 month ago

    Hellwig has some excellent points and people are up in arms solely because he’s not giving the green light for the shiny new toy.

    Keep the wrappers in your code instead of making life painful for others

    This is a perfectly valid approach, anyone claiming he’s resistant for no reason has never tried maintaining a multi language code base.

    If you want to use something that’s not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I’m concerned.

    Again an entirely reasonable approach. There is precedence for this approach in the kernel/dma and I see no reason to change this now, unless a full kernel/dma rewrite to Rust were to occur.