Linus Torvalds on Rust, C, Bugs, and AI Patch-Checking Tools (zdnet.com) 38
"Git and email are the two really only tools I use," Linus Torvalds said at Open Source Summit India 2026. But ZDNet reports that he also shared his thoughts on Rust, C, and patch-checking tools:
"I use Google as a way to look things up." He added, "I'm unusual; most of the other maintainers end up using many more tools, and I think a lot of them are starting to use AI tools for patch checking," while he "works at a higher level. I work with people, not tools."
When asked about Rust both in Git and the kernel, he pushed back against hype: "I'm not sure Rust is going to take over the world. I still think Rust is very interesting, [but] I still find C to be a much simpler tool." Torvalds continued, "I'm much more excited about all the tools we have for verification of C," including "automated patch verification tools" and "automated email checking tools for patches like Sashiko." Summing up, Torvalds told the Mumbai audience: "I'm more of a hack-and-slash kind of person, and I still like the raw and simple power of C, and I don't think that's going to change."
Torvalds also warned against overestimating Rust's benefits: "Rust fixes a few easy bugs that you can make in C, but it does not fix the logic errors, right? It does not think for you, and when you write incorrect code, the language does not matter. The end result will be incorrect." On mixed C/Rust code bases, he pointed out that guarantees are limited: "The guarantees that Rust give you only apply in the Rust-only parts of your code base, and wherever you interact with C code, all bets are off," with most Rust code in Linux talking to "core kernel C code" that is "much better quality... because that code has been tested in every single environment."
At the same time, Torvalds pointed out, "some of our big and more high-profile bugs in the kernel lately have been logic errors" rather than the kind of memory errors Rust prevents.
"It was just bad programming, which sadly happens even in carefully maintained subsystems and important kernels that are supposed to be very secure."
When asked about Rust both in Git and the kernel, he pushed back against hype: "I'm not sure Rust is going to take over the world. I still think Rust is very interesting, [but] I still find C to be a much simpler tool." Torvalds continued, "I'm much more excited about all the tools we have for verification of C," including "automated patch verification tools" and "automated email checking tools for patches like Sashiko." Summing up, Torvalds told the Mumbai audience: "I'm more of a hack-and-slash kind of person, and I still like the raw and simple power of C, and I don't think that's going to change."
Torvalds also warned against overestimating Rust's benefits: "Rust fixes a few easy bugs that you can make in C, but it does not fix the logic errors, right? It does not think for you, and when you write incorrect code, the language does not matter. The end result will be incorrect." On mixed C/Rust code bases, he pointed out that guarantees are limited: "The guarantees that Rust give you only apply in the Rust-only parts of your code base, and wherever you interact with C code, all bets are off," with most Rust code in Linux talking to "core kernel C code" that is "much better quality... because that code has been tested in every single environment."
At the same time, Torvalds pointed out, "some of our big and more high-profile bugs in the kernel lately have been logic errors" rather than the kind of memory errors Rust prevents.
"It was just bad programming, which sadly happens even in carefully maintained subsystems and important kernels that are supposed to be very secure."
Re: (Score:2)
Management (Score:2)
Linus has completed his career migration to full time manager.
Re: (Score:2)
As an aside, I now see where my career went wrong. I never made it to "Seasoned Professional." I need to make my code harder to read.
Re: (Score:2)
Well now, according to the programming career matrix [smart-words.org], he has now made it to middle manager. We look forward to his approach to CEO. As an aside, I now see where my career went wrong. I never made it to "Seasoned Professional." I need to make my code harder to read.
The "Seasoned Professional" code isn't hard to read. It's long because it includes a (very minimal) custom string class. That's something no one should do today (or any time in the last 20 years or so), but it was commonly necessary when writing C++ in the 90s. The STL came out in the mid 90s but wasn't available in many environments for most of a decade afterwards. Of course it would be dumb to write a string class just to write a Hello World program, but if your program used more than a few strings i
Re: (Score:2)
That's something no one should do today (or any time in the last 20 years or so), but it was commonly necessary when writing C++ in the 90s.
Oh yes, but any experienced professional will have developed (consciously or subconsciously) methods for maxxing out whatever metric is being used to evaluate them. Lines of code, whatever. If you are evaluated on LoC I recommend double-spacing.
The difference between the "hacker" (MIT definition [catb.org]) and the professional is revealing. Each is trying to write code that maximizes the perceived requirement. The hacker making the code elegant (in this case, brief), and the professional maximizing LoC.
Re: (Score:2)
That's something no one should do today (or any time in the last 20 years or so), but it was commonly necessary when writing C++ in the 90s.
Oh yes, but any experienced professional will have developed (consciously or subconsciously) methods for maxxing out whatever metric is being used to evaluate them. Lines of code, whatever. If you are evaluated on LoC I recommend double-spacing.
I suppose, though I've never worked in any company that evaluated on LoC. I hear they exist, but I've never seen it... and I've probably worked for two dozen different companies, in a wide variety of industries (I was a contractor for a good chunk of my career).
Re: (Score:2)
Re: (Score:2)
A lot of Agile managers use velocity as a proxy to make up for the fact they can't look at code and understand it. So get a lot of story points.
That is a silly interpretation.
a) stories are estimated independently
b) so the stories "Invite to be my friend", and "invite to my group" - have the same amount of (complexity) points, same for the complementing stories like "Request to join your group" and "sent friend request"
Obviously when any of those four stories is implemented, aka the DB is done, the service
Re: (Score:2)
"the professional maximizing LoC"
if anything that would have been based on how much error-free code a pro could produce.
Re: (Score:2)
The BASIC -> Pascal -> LISP -> C -> C++ progression is very much what most programmers who grew up in the 70s and went to college in the 80s went through, which dates the joke. It was exactly my experience, except that my university didn't do LISP.
You almost got it right. The progression was Fortran -> Pascal -> LISP -> C -> C++ -> JAVA. At least in college introductory programming.
Re: (Score:2)
The BASIC -> Pascal -> LISP -> C -> C++ progression is very much what most programmers who grew up in the 70s and went to college in the 80s went through, which dates the joke. It was exactly my experience, except that my university didn't do LISP.
You almost got it right. The progression was Fortran -> Pascal -> LISP -> C -> C++ -> JAVA. At least in college introductory programming.
The progression in the link isn't what was taught in universities, it was what a programmer learned growing up, and I don't know anyone who learned FORTRAN in elementary and Junior High. BASIC was where it was at (my first code was BASIC to run on a local bank's mainframe -- they were letting my fifth grade "Talented and Gifted" class run stuff -- and then later on a friend's TRS-80; that was all in the late 70s). Then Pascal in high school or college, and so on. Java came later; I'm not sure what the ki
Re: (Score:2)
full time manager.
And one of the most dangerous types of managers: One who knows the technology that he is overseeing.
Re:Old man yells at clouds (Score:5, Informative)
I think anyone whoâ(TM)s worked in a professional setting is going to know the value of code review. Having a tool that can easily give you an extra, high quality code review is incredibly useful.
From the summary.
, "I'm much more excited about all the tools we have for verification of C," including "automated patch verification tools"
Where are you getting that he doesn't like code review tools? Keep in mind that he isn't expected to run them, he's expecting the submitters to run them, which is why he gets testy when he finds obvious errors in submitted patches.
Re:Old man yells at clouds (Score:5, Insightful)
I get the wish to avoid changing your process, and Iâ(TM)m sure Linus puts a lot of thought into how he does things, but I think heâ(TM)s very likely yelling and shaking his fist at the clouds here.
That's an irritating way to say you disagree with him. Just give your counter-argument, don't insult him.
I think anyone whoâ(TM)s worked in a professional setting is going to know the value of code review. Having a tool that can easily give you an extra, high quality code review is incredibly useful.
Are you trying to make the point that AI easily gives you high quality code reviews? It's not clear what your point is or why you don't like Linus.
Re:Old man yells at clouds (Score:4)
The assumption that LLMs can give you "high quality" code reviews is not supported by evidence. It is a pure hallucination by those with AI psychosis.
Re: (Score:2)
It's not sufficient, and it has a lot of false positives, but it can help get a smaller haystack with some of the needles that a human review can miss.
Code review for quality and security is something the LLMs can help without much inherent downside, so long as you do not trust the review but use it instead as an additional pass and make sure you follow up and understand any 'finding'. It *is* a risk if you take it as replacing the need for carefully considered human review, but with discipline you can hav
Re: (Score:2)
The assumption that LLMs can give you "high quality" code reviews is not supported by evidence.
It is.
You just do not read the reports, so you do not know about it.
That is the problem with so many of your posts. About stuff you have no knowledge about, you claim it does not exist. That is a silly attitude.
Re: (Score:2)
Re: (Score:2)
Suppose the question is 'high quality'.
It absolutely floods the field with false positives.
However, depending on the context, you can still see some issues a human is likely to miss. It's an idiot with crazy attention to detail.
So you can't count on it to catch things a human would and in many scenarios it will fire off more false positives than anything vaguely right, but it does represent a value in a more manageable haystack to catch certain issues.
But go back to a reasonable level of skepticism about s
Re: (Score:2)
Re: (Score:2)
That is true, out of 70 reports, only 1 was spot on and only one other was technically incorrect, but it was adjacent to a real problem.
The thing was that as maddening it was to review the 70 reports, the two issues either directly or indirectly responsible were worth it.
However, in an open source ecosystem, you have a whole bunch of users so those 68 bogus 'findings' get repeated for every rando that feels like 'helping' with issues... So open source gets hit harder due to the higher chance for duplicates
Re: (Score:2)
Finding bugs, and reporting, is a different skill set.
And has nothing to do with a code review.
Re: (Score:2)
Re: (Score:2)
No, I don't know it. As I do not know what you are talking about.
Perhaps reread my post you answered to?
Re: (Score:2)
Re: (Score:2)
The comment I answered to did not talk about false positives.
He generally claimed that LLMs are bad in reviewing code: which they are not.
I did not read or answered to any comments about "false positives" - false positives of what?
Re: (Score:2)
The problem with your assessment, is that there is no "the LLM".
LLMs come in a fucking vast spectrum of capabilities.
Put pretty simply, very expensive models do very good.
After very expensive, you get a spectrum from "pretty damn alright", to "outright terrible."
There is no "the LLM."
I can tell from your comment that you're talking out of your ass, and not actually dealing with this problem.
Re: (Score:2)
Re: (Score:2)
I clearly explained the problem- that the quality of LLM-produced output is a function of the money spent to produce it (generally).
This means that the flood of slop PRs are produced by free-to-cheap models. This is only natural.
People who have no idea what they're doing aren't spending $300 for a large commit. They couldn't be bothered to invest the time in learning to code, they sure as fuck aren't going to invest in this.
Mea
Re: (Score:2)
But... (Score:4, Funny)
I work with people, not tools.
But what about when the people *are* tools?
Thought for the day (Score:2)
What if...
Someone (say someone who was familiar with doxygen and GCC) developed number of comment types, where some stipulated preconditions that must be true for the function to run correctly, postconditions that must be true once the function has run, kernel facilities that the function definitely needs, and kernel facilities that the function definitely doesn't need. These would all be optional for any given function.
A static checker could then validate if the code meets the behaviour expected by the pro
Rust vs Carbon (Score:2)
Would not Carbon be a 'better C' to mix it in kernel's ocean of 'C'? Granted - no ready for prime but in concept?
Bugs are bugs (Score:2)
It quicker and easier to write "correct" code in Rust than it is in C, most of the time. And since Rust completely eliminates a class of bug that C can make, it's theoretically easier to focus on "correctly" writing the rest of the code. In my opinion, unpopular though it may be, C is well past it's prime and should migrated away from. If Rust truly isn't good at a specific task, hand it off to a different language, but ideally not C.