Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux

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

Posted by msmash from the ticket-closed dept.
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 More

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

Comments Filter:

  • The last time I remember this kind of discord... (Score:4, Interesting)

    by HBI ( 10338492 ) on Thursday September 19, 2024 @03:20PM (#64800715)

    I seem to remember him writing Git in response.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Not really. SVN is fine for small teams and individuals (I still use it), but for something like the Linux kernel it really does run into ist limitations all the time.

      • I donâ(TM)t really see the point of SVN any more. In used it for years, but wouldnâ(TM)t go back to it. Thereâ(TM)s no reason when you have git. Ok, SVN is easier for less technical people and out old product managers who never really got the concepts of gut. But git is way more convenient and doesnâ(TM)t require a service. I often git init a folder just to give me snapshots or the ability to quickly reset state.

    • No, git was written in response to a very serious crisis in Linux development, caused by external factors. The current dispute about Rust is nothing like that.

  • Reverse Pepperidge Farm precognizates! (Score:5, Funny)

    by Pseudonymous Powers ( 4097097 ) on Thursday September 19, 2024 @03: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.

    • Re: (Score:3)

      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 ...

      • Re: (Score:2)

        by dskoll ( 99328 )

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

        • I'm mostly emacs, but I use vi on occasion because that muscle memory never went away. Primarily the choice is whether I have a GUI or not. So normally I have a GUI so I use Emacs; but sometimes I'm just in a terminal window and then I tend to use vi. Sometimes I'll use emacs in a terminal, since I don't rely on a mouse, but for some reason I default to vi there (brain is too hardwired).

        • Re: (Score:3)

          by caseih ( 160668 )

          Oh interesting. Does Emacs have any decent vi bindings?

        • Re: (Score:2)

          by teg ( 97890 )

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

          "Eight Megabytes And Constantly Swapping" is hardly a problem these days, so we end up with Emacs Macht Alle Computer Schön.

      • 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]

    • Difference is that you can (or at least should be able) to use whatever editor you want. Someone dictating what your day to day tools are seems like a bug in management (must use Craftsman hammers and never Estwing hammers). Many/most projects get along just fine with every developer choosing whatever editor they prefer - it is more productive that way. However letting each developer choose their programming language of choice is going to cause great confusion, because all those pieces of code have to wo

    • 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 @03: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.

    • Re: (Score:2)

      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.

      • Re: (Score:3)

        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.

        • Knowing the programming language is 1% of the job. Or less. I know quite a few people who program with decades of experience who still don't quite know their favorite language :-) In fact there are entire outsourcing industries that exist because they can throw busloads of poorly trained programmers at your project; what they don't have in quality they try to make up for with quantity.

          Rust can prevent some errors commonly made by inexperienced programmers. But inexperienced programmers shouldn't be on su

          • Re: (Score:2)

            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

            • Rust's safety features focus primarily (but not solely) on common errors in application code. Rust therefore would be very god for Linux applications and utilities. However Linux kernel is very different - it is not an application. Many of the things a kernel does feels like bad programming style for an application.

    • 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.

      • Re: (Score:2)

        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.

        • Re: (Score:2)

          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.

  • that's how we know he doesn't care at all (Score:3)

    by dfghjk ( 711126 ) on Thursday September 19, 2024 @03: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.

  • Maybe Rust needs to clean house? (Score:5, Insightful)

    by mrfaithful ( 1212510 ) on Thursday September 19, 2024 @07: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?

  • time to rewrite systemd in Rust (Score:4, Interesting)

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

    time to rewrite systemd in Rust

    pros? cons?

  • Use Rust for a new kernel (Score:3)

    by Meneth ( 872868 ) on Friday September 20, 2024 @05: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.

Slashdot Top Deals

The last person that quit or was fired will be held responsible for everything that goes wrong -- until the next person quits or is fired.

Close