Torvalds Weighs in On 'Nasty' Rust vs C For Linux Debate (theregister.com) 62
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.
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.
The last time I remember this kind of discord... (Score:2)
I seem to remember him writing Git in response.
Re: (Score:2)
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.
Re: (Score:3)
Subversion is fine, the big drawback perhaps is that it is centralized: the repo is in one single server and commits always go there and checkouts come from there. Git is decentralized, which both simplifies and complicates many things. Now Subversion does allow a lot of working locally without access to a server, whereas some other source code control are more tightly tied to a server, whereas Git is completely removed from servers, and servers are technically optional.
But this is mostly a difference in
Re: The last time I remember this kind of discord. (Score:3)
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.
Re: The last time I remember this kind of discord. (Score:4, Informative)
Specifically, there was a licensing issue with Bitkeeper [graphite.dev].
Re: (Score:2)
And now pretty much everyone uses git - Linux, Mac, even Windows devs!
Re: (Score:1)
That'll teach dev tools companies a lesson about working with open source projects.
Re: The last time I remember this kind of discord (Score:2)
Based on this:
Rust into Linux has been brewing since 2022, with critics slamming it as an "insult" to decades of kernel work
Doesn't sound like anything technical. Sounds more like get off my lawn. But who's lawn is it?
Reverse Pepperidge Farm precognizates! (Score:4, Insightful)
"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:2)
What, those vi users are still around? Damn! I thought they had all died out by now!
Also, "vivivi, the Editor of the Beast". ;-)=)
Re: (Score:2)
:append
get off my lawn!
.
v$~:wq
Re: (Score:2)
Ctrl-KKKKK
Nano rules!
Ctrl-SX
Re: (Score:2)
No idea what this "nano" thing is. Probably too small to matter.
C++ is a problem in search of a solution.
I completely agree to that. That thing is just the most horrible abomination I ever tried to write code in.
Re: (Score:1)
Re: (Score:2)
I completely agree to that. That thing is just the most horrible abomination I ever tried to write code in.
C++ is great (not). One can have a fold time job for decades converting "obsolete" C++ code to "modern" C++. I remember spending my first 6 months at a new company converting everything over to C++17. Some of the code was older than C++11 and I had to rework the code dramatically to add move semantics so that the architecture could feel good that we were using "modern" C++.
Re: (Score:2)
Nano is far too big for me, I use Pico!
Re: (Score:2)
No no no, you are supposed to say: "Those vi users are still around? Damn! I thought they all learned how wrong they were and switched."
That keeps the feud going.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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)
I do all my development using emacs. And I know several other developers who use vi or emacs.
Re: (Score:2)
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:2)
Over a remote connection, such as intercontinental VPN connections, a pure text editor without a screen overwhelmed with GUI options is invaluable.
Re: (Score:2)
_Explaining_ the vi vs. Emacs war has become difficult. I use the XKCD cartoon about this:
https://xkcd.com/378/ [xkcd.com]
Re: (Score:2)
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
Re: vim vs emacs (Score:3)
Ah, yes good thing.
The good old "M-x vim-mode" :-D
Re: (Score:2)
"It reminds me of when I was young and people were arguing about vi versus Emacs."
Yeah, I remember those days. Good thing that vim won that one.
Emacs for life, yo! I need my text editor to act like an entire operating system! Eight Megabytes Always Continuously Swapping? Screw you. It shoulda been Sfmacs. Sixty Four Megabytes Always Continuously Swapping!
Re: Good thing vim won (Score:1)
Only on Uranus, not here on Earth.
I had a look at Rust (Score:3)
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)
Having a class of bugs detected at compile time is good, *especially if* it damages productivity.
Re: (Score:3)
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.
Re: (Score:2)
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)
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)
I do not think that is going to work. If you do that the language probably gets very cumbersome.
The correct answer (Score:2)
Re: (Score:3)
Re: (Score:2)
Those who don't learn how to exit vi are doomed to repeat opening new windows.
Re: Fuck C (Score:4, Interesting)
Re: Fuck C (Score:4, Insightful)
How many fad-and-fade languages have you seen with meaningful uptake lasting more than five years, including uptake in the major software development corporations? I'm serious here. I've been programming professionally for a couple decades, and as an amateur for a decade before that, and the closest I've seen to this was Go, which started rising around the same time as Rust, but faded quite a bit when it became clear it was too opinionated (no operator overloading means no drop-in replacements for language features like integers, collections, etc.), sort of badly straddled the boundary between a productive language and a performant language (it got marketed as a faster Python and a more expressive C/C++, but AFAICT, all the uptake was high-level developers looking for something faster, it just didn't provide what systems programmers needed).
And Rust has a lot going for it simply in terms of uptake (ignoring all merits of the language, just how far it's spread). When Microsoft is integrating it into their core products, and Linux is integrating it into the kernel, that's well-beyond where any fad language I've ever seen has gotten.
Re: (Score:1)
The solution is to modify C to make it better. Rust only has a few things that actually make it desirable and those few can be hacked into C. Eventually, those mods would get into official C - rather than wait decades for it to evolve.
Re:Fuck C (Score:4, Insightful)
Are you joking? You have to be joking. If you put even a tiny fraction of the security and stability features of Rust, things that are desirable even before we get into functional improvements, you'd be porting some form of:
And to be clear, some of that is tractable. C++ started with RAII, and in the past decade or so added built-in reference-counted memory management with partial thread-safety (the reference count itself is managed atomically, but the data it points to is 100% unprotected), type-inferencing, and limited forms of destructuring assignment. It also has a concept of iterators, though it's a concept that doesn't fundamentally make them any safer if you're using them manually, rather than via a foreach-style loop. But any attempt to add the safety and security features of Rust to C in a way that was opt-out rather than opt-in (and no, opt-in isn't good enough, because the people who need to do so the most, don't) would break every existing C program, and involve introducing so much new syntax to C that it would be a brand new language.
C++ itself has made historical decisions that mean it can't do a lot of this either. They can introduce better ways to work with iterators, but the underlying protocol is fundamentally unsafe with the standard library types (vector's iterators are glorified pointers; they can't be made safe without undoing much of the performance benefits they rely on, or restricting operations like arbitrary incrementing and decrementing that existing code needs. They can introduces new things, e.g. ranges and company, but they're hamstrung when it comes to removing old, inherently unsafe things.
Sure, you could add a bunch of useful collections types, better threading tools, strings that aren't terrible hacks around simple arrays with a handful of more-or-less insecure APIs to manipulate, etc. Those are nice quality of life improvements. Somehow C hasn't managed to do more than the most basic threading for decades, and it doesn't look like it's even trying. And it lacks any sort of package ecosystem, along with any standard build tooling that might support it (things Rust already has). But none of that is impossible in theory (even if history suggests its impossible in practice). What is impossible is making C any more secure or stable than it is without making into a completely new language.
None of this is to say that Rust is the one and only answer. I readily admit it's hard for beginners to pick up, precisely because of those ownership rules and lifetime issues that are the core selling point for Rust as a secure replacement for C (I know, I've been learning it recently). But I don't know of any competition that is suitable for general systems programming tasks (provides deterministic resource management, low-level access when necessary, high performance, etc.) that isn't C or C++, and the security story for both of those languages is "Don't make mistakes in the first place", a strategy that I'd trust maybe 1% of coders to manage (have you read the CERT Secure Coding Standard for C? I have, I'm a very good C programmer, and even I have trouble remembering to cover every possibility in there), and that's a very optimistic estimate.
Re: (Score:2)
Why do you need any of these IN A LANGUAGE? This all belongs IN A FRAMEWORK. This is like complaining that people don't use English correctly, so instead of making sure your journalists use the AP writing style guide, you need to invent a new language (like Klingon) (and of course just like Rust have that language dominated by a corporatizations , and sue anyone who uses the trademark "Klingon" to denote compatibility with the language)
Re: (Score:3)
Re: (Score:2)
https://github.com/llvm/llvm-project
https://clang.llvm.org/
Re: Fuck C (Score:1)
I'm thinking if you look at all the languages that begin to satisfy the given?
I have to agree with the parent post above...they are all either backend(framework)toolboxes or frontend(framework) toolboxes. Token passing is why things like cgroups, folios, 0 length arrays, are necessary I think.....
Re: Fuck C (Score:1)
RIGHT!!!! So now to fork the kernel rewrite it and show the CS world how it's done!! ./
Re: (Score:1)
This post was written by someone who doesn't use C every day. C is a language that was designed to be a standard, i.e. everything that you can do in hardware, is something that you can do in C, and C is an international standard not ran by a bunch of litigious social justice warriors trying to sue people for using the word "rust".
All of the complaints about by rust devs about C having vulnerabilities and what not, arise not because of C, but rather not running tests on their code and / or using untested cod
Re: (Score:2)
I generally try to avoid responding to AC, but:
This really needs to be Learn to Design. If our software developers were afforded the opportunity to design first, code second, most of the problems would be avoided. Testing is great, but if you don't know what your code is supposed to do (by referencing a design), then what are you testing against?
Yes you can have coding errors, but most errors are due to lack of design discipline, because design isn't as fun and doesn't result in "running code" which is vi
that's how we know he doesn't care at all (Score:3)
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.
Re: that's how we know he doesn't care at all (Score:3)
Welcome to management! :-)
For such a simple word it took you an awful lot of words to spell it.
Parsing difficulty (Score:2)
At first I thought the headline was saying Linus was calling Rust nasty rather than calling the debate nasty.
Stick a FORK in it! (Score:2)
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."
Re: (Score:1)
if you forked it and called it "rustix" they will literally sue you, they are a litigious bunch and their board is dominated by corporations.
balanced headlines go a long way (Score:1)
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:2)
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 i