Linus Torvalds on Rust, C, Bugs, and AI Patch-Checking Tools (zdnet.com)
- Reference: 0184430094
- News link: https://linux.slashdot.org/story/26/07/12/2126243/linus-torvalds-on-rust-c-bugs-and-ai-patch-checking-tools
- Source link: https://www.zdnet.com/article/open-source-summit-linus-torvalds/
> "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 [2]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."
[1] https://www.zdnet.com/article/open-source-summit-linus-torvalds/
[2] https://sashiko.dev/
Management (Score:2)
Linus has completed his career migration to full time manager.
Re: (Score:2)
Well now, [1]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.
[1] https://www.smart-words.org/jokes/programmer-evolution.html
Re: (Score:2)
> Well now, [1]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
[1] https://www.smart-words.org/jokes/programmer-evolution.html
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" ( [1]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.
[1] http://www.catb.org/jargon/html/H/hacker.html
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)
I think it ended in the 90s as a method for evaluation. The best way is to look at the work your programmers have done, but not all managers can do that. 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.
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)
> 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: (Score:2)
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
But... (Score:3)
> 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?
Re: (Score:2)
Almost a dupe - it left out the bit about Godzilla.