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

 



Forgot your password?
typodupeerror
×
Linux

Torvalds Weighs in On 'Nasty' Rust vs C For Linux Debate (theregister.com) 118

The Rust vs C battle raging in Linux circles has left even Linus Torvalds scratching his head. "I'm not sure why Rust has been such a contentious area," the Linux creator mused at this week's Open Source Summit, likening the fervor to ancient text editor wars. "It reminds me of when I was young and people were arguing about vi versus Emacs."

The spat over integrating Rust into Linux has been brewing since 2022, with critics slamming it as an "insult" to decades of kernel work. One maintainer recently quit, fed up with the "nontechnical nonsense." Torvalds struck a surprisingly diplomatic tone. He praised how Rust has "livened up discussions" while admitting some arguments get "nasty." "C is, in the end, a very simple language," Torvalds said, explaining its appeal and pitfalls. "Because it's simple it's also very easy to make mistakes. And Rust is not." Torvalds remains upbeat about Rust's future in Linux, nonetheless. "Even if it were to become a failure -- and I don't think it will -- that's how you learn," he said.
This discussion has been archived. No new comments can be posted.

Torvalds Weighs in On 'Nasty' Rust vs C For Linux Debate

Comments Filter:
  • by HBI ( 10338492 ) on Thursday September 19, 2024 @04:20PM (#64800715)

    I seem to remember him writing Git in response.

  • by Pseudonymous Powers ( 4097097 ) on Thursday September 19, 2024 @04:20PM (#64800717)

    "It reminds me of when I was young and people were arguing about vi versus Emacs."

    Also now that you are middle-aged. And also when you are old. Also, likely, long after you are dead.

    • by gweihir ( 88907 )

      What, those vi users are still around? Damn! I thought they had all died out by now!

      Also, "vivivi, the Editor of the Beast". ;-)=)

    • I call B.S. I barely know any devs who even use a command-line text editor anymore, and if they do it's only for super quick stuff (eg. git commit messages) where no one else knows, let alone cares, what tool they use.

      In fact, I believe the majority of devs these days do the exact opposite: instead of using an editor in their command line, they use a command line inside their editor.

      In IDEs like VS Code, the two are even integrated (eg. you can CTRL or CMD + click a path in the terminal to open the file in

      • I use vi literally all the time - my org requires I use a Windows machine, but all my coding is for c/perl Linux applications.
        • I use vi literally all the time ...

          I use both. Vi for short / quick / simple things; Emacs for longer, more complex things. Different tools for different jobs ...

      • by dskoll ( 99328 )

        I do all my development using emacs. And I know several other developers who use vi or emacs.

      • Over a remote connection, such as intercontinental VPN connections, a pure text editor without a screen overwhelmed with GUI options is invaluable.

      • All this sounds like Emacs to me.

      • I got tired of setting up IDEs in each new environment. At some point, they all became glorified package managers where you're expected to find, install, and configure every feature yourself.

        Now I just use command-line editors and the entire experience is consistent on every device.

      • Even better, I use vim bindings in my IDE.

        Intellij has a decent official vim plug-in (not feature complete, but still quite good). Vscode also has a plug-in, which if I'm not mistaken actually runs a neovim instance inside.

        I don't understand how people can still develop in simple text editors with barely anything more that syntax highlighting (or that require paying with your sanity to make them barely passable pseudo IDEs) when we have IDEs with a bazillion features that basically write the code by themsel

    • _Explaining_ the vi vs. Emacs war has become difficult. I use the XKCD cartoon about this:

              https://xkcd.com/378/ [xkcd.com]

    • Comment removed based on user account deletion
    • And when he was a small kid, people argued about TECO vs QED. Some things never change.

      Random fun fact: As these editors generally were rarely present both in any particular computer, things were relatively calm until they were both ported to Multics and clashed!

  • I had a look at Rust (Score:4, Interesting)

    by gweihir ( 88907 ) on Thursday September 19, 2024 @04:28PM (#64800765)

    I think I would be able to competently code in it. But the skills needed are on an advanced level. Restricted variable mutability. Non-standard restricted OO. Functional constructs. And that is just for starters. Now, I can handle all of these and more of what I saw. And from the PoV of secure coding most (not all) things I saw seem to be good ideas. But I think most regular coders are just lost when they look at Rust and that will not work.

    • by wed128 ( 722152 )
      Reducing the productivity of the vast majority of programmers would be a *good* thing. There is entirely too much software in existence, and what does exist isn't tested or reasoned about nearly enough.

      Having a class of bugs detected at compile time is good, *especially if* it damages productivity.
      • by gweihir ( 88907 )

        Generally, I tend to agree. Not in the Linux kernel-space though. That requires far more skills than just the language used and not many have it.

        • Comment removed based on user account deletion
          • by gweihir ( 88907 )

            Rust can prevent some errors commonly made by inexperienced programmers. But inexperienced programmers shouldn't be on such important projects like the Linux kernel in the first place.

            And that is just the point. Inexperienced coders will just make other mistakes when using Rust. Chances are they will not even have a reduced "error load" overall, and juts make other errors. A mistake in, say, an authentication logic, is not any less severe than a buffer overflow. But that buffer overflow can be used with fuzzing and tools, while that logic mistake probably cannot.

            Hence I am not convinced Rust in the kernel is actually an improvement. It may just give people a false sense of security. For

    • How about leaving the OO and functional type bits out of it, and write simple, practical code as if it were C?

      Data is data, functions are functions, and don't make it more complex than it needs to be.
      I haven't tried Rust yet but I think one can apply the KISS principle just the same.

      • by gweihir ( 88907 )

        I do not think that is going to work. If you do that the language probably gets very cumbersome.

      • How about leaving the OO and functional type bits out of it, and write simple, practical code as if it were C?

        Well that rules out putting code into the Linux kernel, so then what?

        The Linux kernel has plenty of pretty classic OO in it, implemented by hand every time in almost exactly the same way C++ compilers implement OO.

        • by gweihir ( 88907 )

          Hmm. I am not even sure you can do "classical OO" in Rust without going to "unsafe" and hence loosing most of the assurances. In C, sure that is standard and I have done it in some contexts.

          • Rust doesn't have OO; I mean it has "objects" just like most languages have objects of some sort, but it doesn't have inheritance. You can bundle functions with data structures as methods and that is about it.

            You can't avoid the functional aspects in any real sense because the std library uses them. But they are not "real" functional programming in the "let's use monads for everything"; it's much more like python or Javascript.

  • The correct answer is always vi. Always.
  • by dfghjk ( 711126 ) on Thursday September 19, 2024 @04:33PM (#64800789)

    If Linus cared about this topic in the slightest, that would NOT have been his response. And that's how you learn? LOL Linus has always been about having all the answers already.

  • At first I thought the headline was saying Linus was calling Rust nasty rather than calling the debate nasty.

  • Just fork it out into Rustix. You don't need a civil war if both sides just agree to split. Enough are itching to go with Rust; letem' go! "If you love it, you will set it free."

  • Torvalds weighs in on 'nasty' Rust vs C for Linux debate
    Vs
    Rust vs C for Linux - Torvalds weighs in on 'nasty' debate

    Don't know about you, but a more balanced headline goes a long way.

    And this headline somehow made it through the writers head, then the editors. They should both go back and take their 24 hour bootcamp in journalism.

    Please don't correct my writing. I know it's terrible. It's also not my JOB to write headlines being read by the masses.

  • by mrfaithful ( 1212510 ) on Thursday September 19, 2024 @08:47PM (#64801367)

    The problem I see is that literally every time I see something about rust it's antagonistic against C. That's my impression of the language because any time it's ever brought up it's directly challenging some failing of C and how it's "impossible" in Rust and true or not that's obviously going to get the significantly larger C userbase's hackles up. It gaining popularity through its fad status (and arguably managed to get out the other side into actual product) has meant there's a LOT of keyboard warriors in the "community" who produce little else than vitriol.

    I wish I could comment on the language itself but I've written maybe 1000 lines in it and forgotten much of that already. It's not my job to rewrite things in Rust and until it is I'll probably not manage to devote much time to it. I just worry that this laser focus on C's well publicised shortcomings is both overwhelming serious discussion and simultaneously distracting from the fact that C based memory shenanigans are hardly the be-all and end-all of computer security failings. When rust is everywhere, I don't see why it won't adopt many of the non-ptr related failings of external data processing. Rust isn't going to protect you from trusting user input and I'm generally going to assume any web server written in Rust is going to dodge the buffer overflow CVEs but repeat all the "allows access to root folder through carefully constructed URL." It wasn't C that let outsiders access /etc/passwd by adding ../ repeatedly to the URL and if the young rust faithful push out the older experienced devs they are liable to repeat mistakes that occurred 30 years ago, especially if they are mired in the arrogance of having the "superior" language.

    • Inside the Rust help forums there are rarely discussions about "why is this construct better than C". Just questions about "how do I achieve this" or "my code isn't working" or "why does the borrow checker hate me".

      If you are reading sources like slashdot/hacker news or the rest, then it is a different issue. Almost all the stories have some "Rust is better than C" element to them; that's not a surprise, but it's a feature of social media; these are the stories that irritate, excite or annoy people. Either

  • ⦠dislike of C++ doesn't understand why others react the same way to another language?

  • by dr_blurb ( 676176 ) on Friday September 20, 2024 @05:26AM (#64802119)

    time to rewrite systemd in Rust

    pros? cons?

  • by Meneth ( 872868 ) on Friday September 20, 2024 @06:58AM (#64802241)
    Drew DeVault had an idea [drewdevault.com] of moving all the Rust kernel developers to its own OS project, separate from Linux.
  • Linus seems Zen about this whole thing, and it's quite refreshing. He's really is diplomatic about it, and it seems he's looking towards the future and whats coming vs what and who we have now. Younger devs will want newer better languages, Older seasoned vets feel encroached or ignored. That's IT. I'm seeing it now in SAP where there's core SAP, with ABAP and the older modules, the new fancy stuff like HANA and Fiori that's where the splash is. Until everything is replaced, which it never is,

  • vi, of course, As a friend/co-worker put it, 25 years ago, emacs is a windowing operating system masquerading as a text editor.

  • Anyway....

    We get it. Linux maintainers are special, fragile flowers who don't like change or new things. This is boring.

Any given program will expand to fill available memory.

Working...