Torvalds Weighs in On 'Nasty' Rust vs C For Linux Debate (theregister.com) 113
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:4, Interesting)
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: The last time I remember this kind of discord. (Score:2)
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.
Re: (Score:3, Insightful)
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: (Score:2)
The biggest flaw in Subversion is that files have to be added manually to the repo, making it extremely easy to forget to add one when committing. The simple fact that git defaults to including new files is a massive usability win.
Of course git does introduce another issue, that you need to keep the .gitignore file up to date to avoid over-committing, but it's a preferable problem to have.
Re: (Score:2)
You're hallucinating worse than ChatGPT on a bad day!
You have to manually `git add` every file you add to a git repo, too...
Re: (Score:2)
Well, the "default" is that "git add" adds all new files and all changed files. Because that often screws up, it means most people generally do "git add" on specific files. It is nice that "git status" does give you a nice list of what hasn't been added that should. I do like git, I just didn't want to see Subversion maligned as "moribund".
Even in Subversion, may times developers "accidentally" check in their .project that screws up everyone else. (although one consultant did this on purpose and defende
Re: The last time I remember this kind of discord. (Score:2)
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:5, 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, Troll)
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)
It already taught open source projects a lesson about working with conditionally free proprietary dev tools with paranoid owners.
Re: (Score:2)
That's just two sides of the same coin.
Re: The last time I remember this kind of discord (Score:3, Insightful)
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?
Re: (Score:2)
I tried to find what exactly the insult was. As far as I can tell they are complaining that introducing Rust because it has safety features is insulting the work done to secure the kernel.
Re: The last time I remember this kind of discord (Score:2)
Reverse Pepperidge Farm precognizates! (Score:5, 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:3)
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 still read my private email in text-mode via Lynx as converter and mutt as MUA. Works pretty well.
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: Reverse Pepperidge Farm precognizates! (Score:2)
Sounds like they gave you some busy work for the sake of it. Keep the new hire busy for six months while they learn the business. Re-writing code like this sounds like a good way to introduce new bugs.
Re: (Score:2)
Yep. Great for job-security, utter crap for solid engineering.
Re: (Score:2)
Nano is far too big for me, I use Pico!
Re: (Score:2)
Amateur! Femto is where it is at! The "Atto" editor is a bit bizarre though and seems to be a moodle-only thing.
Re: (Score:3, Funny)
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)
Re: (Score:2)
Re: Reverse Pepperidge Farm precognizates! (Score:2)
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:3)
Oh interesting. Does Emacs have any decent vi bindings?
Re: (Score:2)
Oh interesting. Does Emacs have any decent vi bindings?
Obviously. Emacs has everything.
Re: Reverse Pepperidge Farm precognizates! (Score:2)
It has evil mode.
Re: (Score:2)
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.
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)
I heard about this VSCode thing, so I decided to try it. It's a couple hundred megabytes download and installs at closer to half a gig. And it won't run on my laptop. Not worth it just for some autocompletion features I have to figure out how to turn off.
Re: Reverse Pepperidge Farm precognizates! (Score:2)
All this sounds like Emacs to me.
Re: Reverse Pepperidge Farm precognizates! (Score:2)
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.
Re: Reverse Pepperidge Farm precognizates! (Score:2)
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
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: (Score:2)
https://www.youtube.com/watch?... [youtube.com]
Re: Reverse Pepperidge Farm precognizates! (Score:2)
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)
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)
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
Re: (Score:2)
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.
Re: (Score:2)
Modern C compilers are very good at making C safer, *IF* you pay attention to warnings. It's nearly as type safe as C++. Sure, you can typecast stuff away, but C++ allows that too, and C compilers are also warning if you typecast in an unsafe way.
C++ is fine, except that it did too much, there really should be a simpler C+ style that keeps the good stuff of C++ (strong type checking for example) but without the features that add complexity, high level features, or that are just broken (templates). C is low
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.
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?
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)
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.
Re: (Score:2)
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 (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: (Score:2)
That's what :e is for, just reuse the window you can't close.
Re: The correct answer (Score:2)
That's simple. CTRL+T, pkill 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:4, Insightful)
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.
Re: (Score:2)
Since I've seen a project I like die by fragmentation--there are enough developers but none are working on the same fork--that attitude seems like a breath of fresh air. A fork should at least come up with its own name. As all the successful forks you know about have done.
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:5, Insightful)
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.
Re: (Score:2)
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
The man with an irrational and religiousâ (Score:2)
⦠dislike of C++ doesn't understand why others react the same way to another language?
time to rewrite systemd in Rust (Score:3)
time to rewrite systemd in Rust
pros? cons?
Use Rust for a new kernel (Score:3)
Linus will abide... (Score:2)
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,
alt.religion.editors (Score:2)
vi, of course, As a friend/co-worker put it, 25 years ago, emacs is a windowing operating system masquerading as a text editor.
Oh no! (Score:2)
Anyway....
We get it. Linux maintainers are special, fragile flowers who don't like change or new things. This is boring.
Re: vim vs emacs (Score:3, Funny)
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.
Re: Fuck C (Score:3, Interesting)
Re: Fuck C (Score:5, 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: Fuck C but Go? (Score:2)
Re: (Score:2)
All of them? You do know what a fad is right?
Re: (Score:2)
All of them? You do know what a fad is right?
Got any examples? There have been lots of fads, but few of them had meaningful uptake lasting more than five years, plus uptake in major software development corporations. I can't think of any.
Re: (Score:3)
simply because the community surrounding it has absolutely no respect for dissent
After 8 years of actively using Rust (including the FOSS and for-profit organizations), I have yet to see those imaginary hostile "rust communities" which are constantly being referred by anti-Rust trolls. On quite the contrary, the lack of respect is always on the other side.
Re: (Score:2)
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:5, 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, Insightful)
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: (Score:2)
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
I don't trust anyone to manage it. We're human. We make mistakes. On a sufficiently-small task, a highly-skilled and very methodical person willing to commit lots of time can do it, sometimes. When they also get lucky.
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: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