Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming Linux

Linux Creator Torvalds Says Rust Adoption in Kernel Lags Expectations (zdnet.com) 69

Posted by msmash from the closer-look dept.
Linux creator Linus Torvalds expressed disappointment with the slow adoption of Rust in the Linux kernel at the Linux Foundation's Open Source Summit China. In a conversation with Verizon executive Dirk Hohndel, Torvalds said, "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different." This resistance has led to "some pushback on Rust," he said. "Another reason has been the Rust infrastructure itself has not been super stable," he added.
This discussion has been archived. No new comments can be posted.

Linux Creator Torvalds Says Rust Adoption in Kernel Lags Expectations More

Linux Creator Torvalds Says Rust Adoption in Kernel Lags Expectations

Comments Filter:

  • This is a surprise? (Score:5, Insightful)

    by DesScorp ( 410532 ) on Friday August 23, 2024 @02:11PM (#64729836) Journal

    Linux is a C operating system because Unix was a C operating system. This isn't going to change much.

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Friday August 23, 2024 @02:35PM (#64729892)
      Comment removed based on user account deletion

      • Re: (Score:2)

        by lsllll ( 830002 )
        Like they say, necessity is the mother of invention, that is, except all reinventions that fall short of the original one or don't add much. Writing middleware (C, in this case) has become a necessity so many times for me because I'm a grunt (contract, at that) with no control over decisions made by higher ups. Pull the rugs from under me once, shame on you. Do it twice, shame on me.

      • Re: (Score:2)

        by ras ( 84108 )

        Early UNIX developers at AT&T kept getting their hardware taken out from under them, resulting in lost work when they had to migrate to a new hardware platform and a new set of development tools. They wrote a compiler based on BCPL, with an emphasis on hardware portability.

        Back then stuff was written in assembler. Unix V6 cat was as I recall 6 lines of assembler, which with the a.out overheads meant the binary was 152 bytes. Today's cat is a 44k behemoth that also needs a 1.9M libc to run. But criti

      • Did the early Unix developers use other hardware platforms aside from PDP-7 and PDP-11?

    • Re: (Score:1)

      by Anonymous Coward
      You can write shitty software in any language. Even if Rust is better than C, completely re-writing software using a new language is almost never worth the time and effort it takes. Especially when you are talking about a modern operating system, the biggest and most complex software of all.
      • Yeah thats the real danger. The hope would be that new things would be written in rust, like drivers. I don't know kernel or rust well enough to say if thats possible yet. I wouldn't rush in and advocate any high performance highly tuned drivers get rewritten. But you know, wouldn't hurt to re-write that printer driver in rust if possible. But of course " wouldn't hurt" doesn't exactly move the needle and cause companies to open their wallets at dev efforts. The next version of the driver is still going t

        • But you know, wouldn't hurt to re-write that printer driver in rust if possible.

          Practically very little of the printer drivers are in kernel. Most of the data processing where vulnerabilities would be is in user-space. So rust in the kernel isn't going to help much there.

          Never-mind that most people using printers in this day in age *really* hate it when their printer stops working. As the hard copy tends to be a hard requirement imposed by others for most of them. They aren't going to want to deal with their their workflows being fucked up because a printer driver was completely rew

    • It's more subtle than that: the kernel is a highly important component of the OS, and kernel bugs have a high profile and large associated cost to literally millions of people. That means don't rush the code logic. The language used is irrelevant, since logic is difficult in every language.

      Rust is considered great by kids who learned Java in university instead of taking courses in discrete math and logic. For the rest of us it's just another language which doesn't help make the logic part any easier. .

      • I was going to say. I am not agent using Rust in the future, but it just seems everyone is just trusting the language rather than the compilers that run with it. It has taken decades for compilers to get the kind of result we want with -O0-3 and the kind of optimizations you need to do for Rust make me confident it can be done even in this decade.

    • Re: (Score:2)

      by Kisai ( 213879 )

      This is true, and it would be absolutely fine to continue that way. There should be no rush to convert the kernel to Rust.

      Rust needs to be guaranteed FORWARD compatible before making a full commitment to learning it. Many languages do this nasty "depreciate, dispose and refactor instead of just-fix-it"

      We can not treat the kernel like PHP and Python. That is a bad thing to keep breaking API's because the old API doesn't support the extra arguments needed to make it safer. That's why the _s C functions that m

  • Benign Neglector for Life (Score:4, Funny)

    by Pseudonymous Powers ( 4097097 ) on Friday August 23, 2024 @02:17PM (#64729850)

    LINUS: [spends decades carefully cultivating a vast stable of misanthropic neophobic curmudgeons]

    ALSO LINUS: [is astonished when misanthropic neophobic curmudgeons act in a neophobic and curmudgeonly fashion]

    • I did not read it that Linus was "astonished" as if anything surprised him. He was disappointed that more adoption has not happened. Just like when my sportsball team has a terrible season after many terrible seasons. I hoped this season would be different but not surprised when it was not different.

    • Re:Benign Neglector for Life (Score:5, Funny)

      by Anonymous Coward on Friday August 23, 2024 @03:46PM (#64730182)

      RUST FANS: [beg, whine, complain, and harass Linus about allowing Rust in the kernel..]

      LINUS: [finally agrees to allow Rust in the kernel]

      DEVELOPERS: [keep using C]

      NOBODY: [shocked]

  • Novelty wore off (Score:4, Interesting)

    by xack ( 5304745 ) on Friday August 23, 2024 @02:21PM (#64729858)
    Once they got the goal of "rust in kernel", it got abandoned, just like all those "rewrite it in rust" projects littering git repositories everywhere. "C" how many "c killers" are now abandoned.
    • I'm honestly not sure why would I bother with C/C++ killer when they have mostly cosmetic improvements yet require redoing/relearning everything again from the start. It's simply not worth it. Only a paradigm shift would justify more learning, like going pure functional. C-likes are simply not different enough and thus boring.

      • yet require redoing/relearning everything again from the start

        life of a Perl programmer

  • First ... (Score:5, Funny)

    by PPH ( 736903 ) on Friday August 23, 2024 @02:24PM (#64729868)

    ... do systemd in Rust.

  • Not better enough. (Score:5, Insightful)

    by jythie ( 914043 ) on Friday August 23, 2024 @02:33PM (#64729888)
    A classic issue in trying to get people to switch to a new system : it can't just be as good, it can't just be better, it has to be significantly better. Rust isn't currently even as good as C, far from the 'much better' needed for adoption.

    • Especially when it has no tangible benefit, after all the "integration" and "optimization" and "paradigm compliance" have been applied.

      • From The Mythical Man Month, as systems get complex, there is a lower bound to how many errors the system has. Any attempt at fixing known errors will introduce even more errors.

    • Re:Not better enough. (Score:4, Insightful)

      by ZeroPly ( 881915 ) on Friday August 23, 2024 @03:17PM (#64730044)
      "Better than C" isn't enough. It needs to be so much better that a programmer is willing to devote hundreds of hours of their life to learning all the language features, the paradigms, reworking their coding workflow, and on and on. There are about a brazillion languages out there looking for a reason to exist. But I already know how to write C/C++ code, and I don't have a big bucket of time sitting in my garage.

      • Re: (Score:3)

        by tlhIngan ( 30335 )

        Exactly. Also, kernel development is a specialty skill. It's quite different from programming an application. And the end result can easily end up like what happened to CrowdStrike.

        So you're asking these programmers who know a very specialized task, to change their ways. It needs to be worth it to them to invest their time and effort into doing so. At the same time, they probably need to look at C code to figure out something in the kernel, so they're going back and forth constantly.

        And it needs to be compl

        • Yea you could say that about the compiler too. How many decades did it take for optimizations to become standard. Hell its only recently that "register" was depreciated. Rust, as a language is nice, but not sure you can get away with the stuff you need to get x64 to boot.

      • Learning another language isn't hard

        • Re: (Score:2)

          by ZeroPly ( 881915 )
          LMAO - if you think learning a new language isn't "hard", then you shouldn't be doing any development work in a professional capacity. There are too many of you types out there who've learned the language features in a 3 month boot camp, and now fancy yourselves developers. I'm not talking about learning how to do a while loop or write a Towers of Hanoi program. I'm talking about modular organization, language idiosyncrasies, etc etc.

      • Re: (Score:2)

        by jythie ( 914043 )
        I think that is actually part of the appeal. They are looking for people willing to invest that kind of time and effort in order to demonstrate how 'in' they are.

    • Re: (Score:2)

      by CAIMLAS ( 41445 )

      Came here to say this.

      If you want Rust to supplant C, you've got to up your game and provide more value in the Rust tooling.

      "Not very stable" is not exactly close to what's required to win.

      • Re: (Score:2)

        by gweihir ( 88907 )

        Came here to say this.

        If you want Rust to supplant C, you've got to up your game and provide more value in the Rust tooling.

        "Not very stable" is not exactly close to what's required to win.

        Indeed. And for a kernel developer, it is essentially a big red "STAY AWAY" sign.

      • Or make a new OS based on Rust, from ground up. Why are there so many languages? Because people wrote them! So why not write the OS and prove that it can be better? Writing new from scratch might be easier than retrofitting as well.

        • Redox.

          But I wonder what progress a small army of volunteers can make on 'real hardware' when the strength of Linux over other FOSS projects is drivers.

          Whether GPL'd Rust kernel modules running in userspace on a MIT licensed microkernel would constitute a derivative work...

          • Re: (Score:2)

            by CAIMLAS ( 41445 )

            So build your OS around the linux kernel driver architecture to enable it to use them natively.

            FreeBSD has effectively done this with LinuxKPI.

            Or hell, just borrow/rewrite that.

        • Re: (Score:2)

          by jythie ( 914043 )
          And this gets to one of the hearts of Rust.... it isn't about making YOUR programs safe, it is validating that other developers you interact with are also doing things 'the right way'... your way. Writing their own OS would be preaching to the already converted, they want others to have to play with them and follow their rules.

    • Re: (Score:2)

      by gweihir ( 88907 )

      I recently had a look at Rust. There are some nice features, but my overall impression is that it is _hard_ to use. Functional concepts, non-standard OO and some other things may all be good ideas from a language evolution point-of-view (for example, standard OO is essentially a failure and did not deliver on its promises), but these things take more skill and experience and diverse language experience than the typical coder has and a C coder needs to learn several new ways to think.

      Add the toxic community

    • Re: (Score:1)

      by jimjoe ( 527975 )

      it can't just be better, it has to be significantly better. Rust isn't currently even as good as C

      I wish someone would give Prescheme [prescheme.org] a try, for this. Compiles to C anyway for now, so the path should be easier.

  • It's called status quo bias. It can be turned around, but it'll take some time.

    • Memory safe in a kernel is not the same as memory safe in an application.

      • Re: (Score:1)

        by ka6wke ( 306232 )

        Memory safe in a kernel is not the same as memory safe in an application.

        Not sure how your comment applies to my observation. I'm talking about human behaviour, not memory management approaches.

  • The intersection of people who are into embedded / kernel level programming, and those who come from erlang / haskell heritage is vanishingly small.

    I do not know why, but they insisted on the older ocaml syntax with some C and Swift influences, instead of going with what is common.

    And while this might seem superficial, it is also a real barrier to adoption. When I had to learn C#, I could use my Java experience and a side-by-side cheatsheet to ramp up. Similarly Java learning was based on C++, which was eas

    • Most embedded work requires specialized tooling, so Rust isn't even an available choice.

      That's yet another problem in adoption; kernel programmers might also be embedded programmers, who literally can't switch, and they're not interested in programming in an extra language concurrently. It just adds complexity for the human, with little to no gain.

  • OK, perhaps I'm too old for this shit!
    I code mostly in C for embedded systems and C++ for desktops.
    Age must be the culprit. I remember quickly switching between many languages at university, or at the beginning of my career. But no more, not much. Bash scripting is OK. A little bit of Python sometimes. But Rust ...
    I tried the Rust tutorial two time. And I feel something odd: the syntax employs keywords and <what are they called again ? (&! ...)>, that are messing with my brain, mainly because I

  • Stability of rust is a huge problem. It is not a very solid platform yet to develop for. Which goes counter to what it is supposed to be.

  • I will keep repeating this: Rust was created at Mozilla to address the vulnerabilities found in Gecko engine written in C/C++ and to leverage on concurrency programming. Servo [wikipedia.org] was the project in which Rust should have been proven right. It was never finished... after 12 years.

    Rust is propaganda, a political stance, a social stance. Rust is anything but a programming language.

    Rust should be considered the same as Cryptocurrencies, A.I. Hype and Virtual Reality headsets.

    • Honestly I would say Rust is a very good language to write parsers for OTHER languages. I mean building a lexer and parser in C/C++ is a bitch but you can get one done in a weekend in Rust with tree optimizations. Runs slow though but it works.

    • No, Rust isnt a waste a time and resources in itself like Crypto. It is a perfectly usable programming language, stuck to a toxic community and the unsafest build system known to man.

  • That's the problem. It's not very nice to mix C and Rust in one module. So it's only for new modules/subsystems or they would have to rewrite existing code (and in places with multiple mantainers/contributors that can be tough).

Slashdot Top Deals

If it wasn't for Newton, we wouldn't have to eat bruised apples.

Close