Linus Torvalds Says Rust For The Kernel Could Possibly Be Merged For Linux 5.20 (phoronix.com) 157
Speaking this week at the Linux Foundation's Open-Source Summit, Linus Torvalds talked up the possibilities of Rust within the Linux kernel and that it could be landing quite soon -- possibly even for the next kernel cycle. From a report: Linus Torvalds and Dirk Hohndel had their usual Open-Source Summit keynote/chat where Linus commented on Rust programming language code within the kernel. Torvalds commented that real soon they expect to have the Rust infrastructure merged within the kernel, possibly even for the next release -- meaning Linux 5.20. There hasn't yet been any Rust for Linux pull request sent in or merged yet, but things have begun settling down in the initial Rust enablement code for the kernel with the basic infrastructure, a few basic sample drivers, etc. Last month saw the most recent Rust Linux kernel patches posted that got more functionality into shape and additional reviews completed. As noted plenty of times before, this Rust support within the Linux kernel will remain optional when building the kernel depending upon whether you want the support or any of the kernel features to be implemented just in Rust code.
Most secure OS ever, incoming. (Score:2, Funny)
Re: (Score:2, Insightful)
I think you're being a little fanciful with that idea. If people cared about issues caused by the size of the attack surface, Windows would have been sidelined years ago.
Re: (Score:2)
Re: (Score:2)
You said "not after midnight".
Re: (Score:2)
That was for Gremlins!
Lol no. Mostly one problem, same as modem C (Score:5, Informative)
I track and report on vulnerabilities as part of my job, and have for a long time.
No, it will not "greatly decrease" anything. Mostly Rust attempts to protect against one type of error that matters. Modern C, for at least the last 11 years, also protects against the same type of error. Then Rust tries a couple other things that are not a significant percentage of security vulnerabilities.
Rust might be a decent language. The Rust fanbois definitely make ridiculously over hyped security claims in decades. In the Slashdot tradition of car analogies, here's what their claims sound like to a career security professional:
Rust project:
The new Toyota Rust is so much faster than other cars! No more "are we there yet?"!
* The Rust has a top speed of 92 MPH, vs 90 MPH for the competition.
Rust fanbois, who mostly aren't even programmers and have never used the language:
You're still driving to California? Why didn't you just use Rust so you'd get there instantly? Rust pretty much goes lightspeed, ya know.
But the most fun is when they trumpet things that apply to most any language. Which is a like a car fan shouting "this car has cupholders!"
Re: (Score:2)
This is my gripe: the hype train. What immediately sets off my skeptic alarms is when something comes with all benefits and zero drawbacks. Then I know it's just marketing talk. There's a single person in our devices software department, with maybe 300+ actual developers around the world, and he's often pushing Rust at the highest levels. He goes on and on about how it will solve all our problems with bugs, but never once mentions any drawbacks: learning curve, rewriting millions of lines of code, testi
Re: (Score:2)
What class of bugs are talking about? Nothing in modern C and C++ standards do much to prevent memory access bugs, which are still the leading cause of exploitable bugs in all the surveys I've seen. Improved tooling like AddressSanitizer have greatly decreased the number of memory access bugs in my C/C++ code from getting to production, but some still do in my code, and in other large C/C++ code bases that I know are using best practices.
Rust eliminates those entirely, except in unsafe blocks which I rarely
Re: Lol no. Mostly one problem, same as modem C (Score:2)
Everything in modern C++ prevents memory errors.
You really have to get out of your way to do something stupid to get them.
Re: (Score:2)
I think a better analogy would be: it comes with seatbelts, so now entire classes of crashes go from lethal to not a big deal.
"But aren't seatbelts just a standard feature on cars?" Yes, yes they are. And people argued against them just like you're arguing against Rust now.
Re: (Score:2)
"Rust's memory safety is like a car that comes with seatbelts" doesn't mean Rust is a seatbelt.
Re: (Score:2)
C sounds very manly. Glad I've been using it for the last 25 years. But at this point now I have way too much hair on my chest. I should have switched over to Lisp or Haskell maybe 5 or 10 years in.
Re: (Score:2)
But at this point now I have way too much hair on my chest. I should have switched over to Lisp or Haskell maybe 5 or 10 years in.
Lisp and Haskell are unconcerned with the amount of hair on your chest, it's your neck that matters.
Re: (Score:2)
Haskell may appeal to neckbeards, but at least I'm not using Java or C#.
Real manly men use Ada and make missiles and fighter jets.
Re: (Score:2)
Haskell is going through a bizarre resurgence among non-neckbeards, but still, most Haskell hardons exist below a wall of unkempt facial hair.
Note: I say these things with nothing but love
Re: (Score:3)
I'm trying to switch careers from being a competent engineer to being a below average manager.
Re: (Score:2)
If that is the case, then why are the C equivalents of ripgrep and fd-find slow as hell?
Re: (Score:2)
and finally will overtake Windows as the OS of choice among the corporate world
Normally I'd say this is deserving of a funny mod, but honestly there's so much stupidity on Slashdot that I think this along with the rest of your post is actually you being serious. Wow.
Re: Most secure OS ever, incoming. (Score:2)
Welcome to our Rust overloads I guess (Score:5, Interesting)
Like many here, I am a little reluctant to having Rust in the kernel but I guess Linus knows better.
From what I read before, Rust would only be used for drivers and modules. Does anybody knows if it is planned to use Rust in the core of the kernel as well?
I read about potential issues for platforms where the Linux kernel runs which don't support Rust. I guess the kernel could then be cross compiled for the target platform on another platform that supports Rust but it is a wild guess. Anybody knows more about that than I do?
Anyway, having Rust in the kernel would be a good reason for me to learn it I guess.
Re: (Score:2)
You could cross compile the kernel, but if you were serious about it, you'd start by cross compiling the Rust compiler. Since it's an LLVM compiler the back end hard work is already done for any platform you're likely to come across, so it's just a matter of cross compiling the front end, then your platform is a rust native platform.
Re: (Score:2)
Rust isn't available for every architecture and has tons of dependencies for building. How do they plan to keep it from creeping into platforms that can't build the rust toolchain?
Re: (Score:2)
Re: (Score:2)
Re:Welcome to our Rust overloads indeed (Score:2)
Like many here, I am a little reluctant to having Rust in the kernel but I guess Linus knows better.
Do not be reluctant, change is good. And memory safe languages are good as well. And, while Linus is human, and therefore fallible, in his domain of expertise (the Linux Kernel) he probably know better, so right you are.
From what I read before, Rust would only be used for drivers and modules. Does anybody knows if it is planned to use Rust in the core of the kernel as well?
For the time being, no, only drivers and modules. But hopefully, in the future, as both Linux and Rust evolve, maybe, the door is not locked, and dare I say, is not closed either (is ajar).
Also, there is a parallel effort to move Linux out of GCC and into LLMV (a very worth and important eff
Re: (Score:2)
There's a difference between knowing better and caring. Linus used to have a reputation for being a hardass and putting technical correctness over peoples' feelings. Lately, I think he's been getting tired of the politics and has been conceding to too much nonsense.
There's still a debate over the facts that Rust lacks a formal standard, core feature development is still in flux, and only has a single implementation available. I really, really don't think that's an acceptable platform to be using for an O
Re: (Score:2)
Tools can't make code not suck, but tools can indeed stop you from making stupid mistakes and be safer or less safe to use.
If you want to see how to really make stuff safe, look at the aviation industry, where they look very seriously at how to make sure the right thing happens, and don't blame the pilot for every single mistake. One of the things that makes modern airplane travel so safe is that often a problem results in concluding the design needs improving to stop the same thing from happening again.
Thi
Re: (Score:2)
This is very much unlike the computer industry, which is still resistant to the idea that maybe a system where you can go past the end of a buffer by adding 1 too many is just dandy.
It's not the computer industry that's resistant to such things, it's the processors themselves.
As soon as you can stop a load instruction from overrunning a buffer at the hardware level, we should be able to completely eliminate that class of exploits!
Or... understand your own ignorance and don't formulate strong opinions about things you know nothing about.
Re: (Score:2)
The processors don't really matter, if the compiler never emits any code that can lead to overflow. It doesn't really matter in the end whether it's the CPU that does bound checks internally, or the compiler always emits bound checking code, or code that never breaches bounds. Any of those approaches works.
Also, Intel tried something like that with MPX, didn't quite work in the end.
Re: (Score:2)
The processors don't really matter
Nonsense.
if the compiler never emits any code that can lead to overflow.
There are many compilers that do this.
But ultimately, the hardware does not, and thus there will *always* be some amount of software that necessarily does not.
We do not live in a world where hardware conforms to our (mis)conceptions about how software interfaces really work.
It doesn't really matter in the end whether it's the CPU that does bound checks internally, or the compiler always emits bound checking code, or code that never breaches bounds. Any of those approaches works.
It matters very much, because 3) is available to anyone, 2) is available to most software languages, and 1) does not exist.
Since 1) does not exist, and it's impossible to implement an operating system entirely in 2) or 3), we
Re: (Score:2)
Ahh, I see you've never used IAR's C IDE and compiler. True story: interrupt handlers can be written in pure C. (The compiler performs the necessary tricks behind the scenes to deal with the modified stack frame and "return-from-interrupt-handler" instructions.)
Re: (Score:2)
Many C compilers designed for specific platforms have extended the language to support the intrinsics required.
IAR is one such example, which is why it was once-upon-a-time basically the only toolchain that professional Arm development was done on (myself included)
Re: (Score:2)
As soon as you can stop a load instruction from overrunning a buffer at the hardware level, we should be able to completely eliminate that class of exploits!
Good one!
Or... understand your own ignorance and don't formulate strong opinions about things you know nothing about.
Indeed. The problem is not the buffer overrun. It is a symptom pointing to the real problem and that is sitting in front of the keyboard. Buffer overruns are easily avoided in development and easily found in testing and symbolic analysis. These people completely ignore that systems written in languages that do not allow buffer-overruns have a lot of security problems, probably a lot more. They are just not so easily classified, so you get a large number of smaller numbers instead of one large one.
Re: (Score:2)
Programming languages / compilers help us maintain all kinds of invariants about our software
A perfect example.
In a world where all inputs, outputs, and code are generated by your compiler, with no function to circumvent it- yes, this is true.
The problem is that this situation does not, cannot, and will not ever exist on any personal computer.
Re: (Score:2)
I apologize if I made you feel stupid at some point.
I'm a professional with decades of experience and global recognition of my work. It doesn't mean I'm infallible, but it does mean I'm damn fucking good at what I do.
Baseless insults from ACs can only really come from one place: You said something stupid, and I called you out on it. Your parents probably could have educated you to handle situations like that, but oh well. Here's your participation trophy.
Re: (Score:2)
I don't know what's up with that huge chip on your shoulder, but no amount of personal accomplishments justifies being this unpleasant.
Programming today is a team effort. If you can't be an useful part of a team you'll eventually be replaced with somebody who can, even if they're less technically awesome.
Re: (Score:2)
I don't know what's up with that huge chip on your shoulder, but no amount of personal accomplishments justifies being this unpleasant.
I don't need to justify myself to you.
I was responding to an insult.
Programming today is a team effort. If you can't be an useful part of a team you'll eventually be replaced with somebody who can, even if they're less technically awesome.
I await the day. I've done my part.
Re: (Score:2)
A completely irrelevant comparison. You are comparing production use by users with development by developers. It is clear why you do that: You are wring but do not want to admit it, so you are looking for an "example" just far away enough to still seem plausible, but to actually be something different.
Here is a thing, in the same venue as yours: Kitchen knives are dangerous. Yet every chef uses one even more dangerous than the average amateur, the sharper the better. Why? Because it is a good tool. It just
Re: (Score:2)
There's more danger from other brain dead and obsolete technologies like relational databases
That one broke my brain a little bit. Maybe I'm just getting old, but what the hell is the alternative for financial/transactional systems and such?
Re: (Score:3)
There is no real alternative. Some people just don't like stable and reliable technology. They think it's boring.
I remember an Oracle sales drone trying to sell us whatever their OODBMS product was at the time, claiming that relational databases were going to soon be obsolete, more than 20 years ago. I can't remember if I laughed out loud or not.
Re: (Score:2)
They think it's boring.
Being the the ERP world I can tell you, unequivocally, that boring is good thing.
Re: (Score:2)
He was just looking for a way to sue you.
Comment removed (Score:4, Insightful)
Re: (Score:2)
Re:Welcome to our Rust overloads I guess (Score:4, Insightful)
Let me know when a Rust "Hello, world" is under a megabyte.
Rust is currently a language for dabblers and language weenies. It doesn't solve any problems, it just pushes awareness to the coding phase. This isn't a bad thing but it's no panacea to coding errors.
My boss is going to force all new development to Rust in the near future because he thinks it will fill all coding issues. We work in a field that requires ISO26262 compliance, which Rust does not have. He's a moron and I'll be looking for a new job when that mandate comes into force.
Re: Welcome to our Rust overloads I guess (Score:3)
Re: Welcome to our Rust overloads I guess (Score:2)
Re: (Score:2)
As an embedded developer, I need solid tools, so Rust is currently out.
Re: Welcome to our Rust overloads I guess (Score:2)
Re: (Score:2)
ISO26262? Oooh ~ FuSa! I do chip logic with FuSa goodness it it. Doing that with software seems like it might be hard work, given that it has to run on hardware that might not be so blessed.
Re: (Score:2)
Let me know when a Rust "Hello, world" is under a megabyte.
Why? The ultimately size of something should only be a goal in a very VERY particular circumstance. We're talking about allowing it for drivers, we're not talking about using Rust on an 8bit microcontroller with 4k of program memory.
The rest of your post is quite sane so this one comment of yours stood out as particularly stupid.
Re: (Score:2)
Re: (Score:2)
In your specific circumstance I agree. But you were replying to someone else who doesn't seem to be an embedded developer. Maybe don't apply your personal and highly specific selection criteria in a general sense onto other people's applications?
I know its hard. Programmers and Engineers love jumping to conclusions without ever giving a damn what the problem was in the first place.
Re: (Score:2)
It's really quite something to see the people who aren't developers who read about Rust and think the world would be a better place if Rust was the new dominant language because it would "fix all those dumb buffer overflow and security issues from them" without understanding it won't and can't. The last language that tried selling that was ADA, and we all know how that turned out.
Re: (Score:2)
Yes, it's a young language still and doesn't have ISO standard yet. With that logic you'll be still coding by punching holes in the cards cuz they were well-standardized then and every piece of new stuff was just crap because no ISO.
You can fit it into whatever size you want, by not using stdlib or linking dynamically (the default is static). Besides it's
Re: (Score:2)
> Let me know when Rust has an ISO standard so multiple vendors can make compliant compilers.
Irrelevant for the kernel given how many GCC-specific features they are dependent on. The main reason that you can now compile the kernel with clang is because clang support for those extensions has improved.
> Let me know when a Rust "Hello, world" is under a megabyte
Easy, pass the flags to dynamically link the standard library (like C does by default), and strip symbols, and hello world is ~16K. That is pret
Re: (Score:2)
>Irrelevant for the kernel given how many GCC-specific features they are dependent on. The main reason that you can now compile the kernel with clang is because clang support for those extensions has improved.
Irrelevant? I do ISO26262 safety critical coding for some of my job. No standard and no certs means it's a non-starter at work, yet the boss is going to force it. Why? He read it'll fix all memor
Re: (Score:2)
It doesn't solve any problems, it just pushes awareness to the coding phase. This isn't a bad thing but it's no panacea to coding errors.
You are the third person that seems to suggest that Rust claims to prevent all bad code. No one has said that ever. Rust has features that prevents some common mistakes in C like null pointers. Features like automatic garbage collection in newer languages like Java does not mean a programmer can assume the machine has an exabyte of RAM. These features are designed to help with some aspects of older languages. They are not an excuse not to avoid good coding practices.
Re: (Score:2)
It is most certainly not
Re: (Score:2)
Rust is being sold like it's a panacea for all memory issues. It is most certainly not.
Citation needed. Please cite anywhere where Linus or anyone in kernel development said anything of the kind. Again, Rust has safety features beyond that of C. This is why it is being considered. Your interpretation of the capability of Rust does not apply to everyone.
Re: (Score:2)
Re: (Score:2)
Let me know when Rust has an ISO standard so multiple vendors can make compliant compilers.
This is a real problem. There's an old proverb about putting your eggs in one basket that would seem to apply here. I also don't expect to see multiple implementations in the near future, given the complexity involved.
I really like what Rust is trying to accomplish, but I see it as more of a 'first try'. I expect that future languages with similar design goals to be simpler to use and simpler to implement.
Re: (Score:2)
Let me know when Rust has an ISO standard so multiple vendors can make compliant compilers.
Let me know when C Compilers standardize on compatible binaries. :D
Re: (Score:2)
Back when I programmed games we would typically have four or more toolchains, but each was for a different target arch. The code had to compile cleanly under each but never did we try to link a PPC lib to a MIPS executable. :-)
Re: (Score:2)
My boss is going to force all new development to Rust in the near future because he thinks it will fill all coding issues. We work in a field that requires ISO26262 compliance, which Rust does not have. He's a moron and I'll be looking for a new job when that mandate comes into force.
Yeah. Like software written in Java, PHP, Python, etc. does not have security problems.
Re: (Score:2)
It is people like you that are responsible for insecure and bad software. You are barking up the wrong tree because you do not understand the problem. Pathetic.
And as so many others you do not even understand the distinction between productive use of something and creating something. Even more pathetic.
rust trademark issues (Score:2)
probably a good idea to get the Trademark issues resolved before that happens
* https://lists.debian.org/debia... [debian.org]
* https://news.ycombinator.com/i... [ycombinator.com]
* https://news.ycombinator.com/i... [ycombinator.com]
Re: rust trademark issues (Score:2)
Quick. Someone snag the trademark for "IronOxide".
Re: (Score:2)
Re: (Score:2)
He (and all other contributors) have already granted permission if you follow GPLv2. If you don't follow that the lawyers tend to get involved.
Re:rust trademark issuesn (Score:2)
Re: (Score:3)
Logical renaming:
Linus + Unix = Linux
Linus + Rust = Lust
Nevermind, scratch that.
Embrace... (Score:2)
... extend...extinguish. Lets see whether the Linux Kernel will eventually be on MS-crap level. It seems likely of this is not stopped.
Re: (Score:2)
What are you even on about? Rust is a Mozilla project.
Re: (Score:2)
Re: (Score:2)
False sense of secure software development (Score:2)
The main objective of Rust is safety, in particular in memory management. It's like saying that unsafe code resides just in the language in which software is implemented.
Which is a big illusion since producing secure and safe code is not a panacea that lives in a programming language but it is an attitude.
Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.
Eve
Re: (Score:2)
Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.
As far as I know no one has ever stated that the goal of Rust was to prevent all bad code. Certain features in Rust prevent common problems like null pointers by making them difficult to do.
Even more, Rust will produce a new generation of software developers that will not know how a computer works. Until the computer is reinvented using another paradigm then it's mandatory that software developers get use to the unsafe situations of handling memory.
Well that is a stretch of logic and a bit elitist. I know lots of programmers who have never coded in assembly or C or C++ but they know how computers work. Java and Python programmers never really concern themselves with garbage collection that C requires. Are they lesser programmers in your eyes?
Adding in safety featur
Re: (Score:2)
Antilock braking and air bags does not mean that people no longer have to know how to drive.
Furthermore ABS and Air bags have saved many thousands of lives. OP is following the same absurd logic that used to be prevalent in the safety industry.
"Oh you were injured in a car crash? Well that's your fault, you must have been driving like a maniac!"
It took Ralph Nader's "Unsafe at Any Speed" to cut through this bullshit corporate propaganda that you need to protect users even when they make stupid mistakes.
Similarly 70% of security problems are memory safety. If Rust reduced our security vulnerabili
Re: (Score:2)
I know lots of programmers who have never coded in assembly or C or C++ but they know how computers work.
* In the voice of Mick Dundee * "That's not a knife. THAT'S a knife!"
All joking aside, I will put my dollar against yours, in that someone who has never coded in assembly doesn't knows how computers work. How a computer works is in and of itself very multi-leveled. It's one thing to understand how you load a register with a number and use an ADD instruction to add to it, and then it's an entirely different thing to know what the processor actually does when it's running that ADD instruction. Of course m
Re: (Score:3)
Java and Python programmers never really concern themselves with garbage collection that C requires. Are they lesser programmers in your eyes?
Yes. If you're using a gc language like Java or Python and you're not thinking about memory, you're definitely a lesser programmer.
Re: (Score:3)
Except garbage collection is not the same as thinking about memory. You can any program to consume way too much memory.
Is the amount of memory used really the only issue you think is relevant here? Does your username check out?
Re: (Score:2)
Java and Python programmers never really concern themselves with garbage collection that C requires.
I want to give you the benefit of the doubt that this was a typo, but to make things clear, C does not have a garbage collector. C inherently doesn't have an issue with losing memory associated with objects. The programmer does the job of the garbage collector by freeing allocated memory at the end of routines, whether the routines were successful or not, as long as memory was allocated.
Re: (Score:2)
If you rely on humans to be perfect, you'll always fail.
You're essentially saying Rust is pointless because a perfect human wouldn't make mistakes and therefore wouldn't need any of Rust's features. Ok... let the world know when you find this god like mythical developer who never makes a mistake.
Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.
Nobody has ever suggested that Rust will prevent code from crashing.
Even more, Rust will produce a new generation of software developers that will not know how a computer works.
These Compilers and high level languages like C will produce a generation of software developers that will not know how a computer works! Everythi
Overall, good news. (Score:4, Interesting)
What is the big problem with C for Linux kernel? (Score:2)
Not C++, just C.
I know that one big problem is memory management. But is that really an insurmountable issue?
Sometimes OO is the only practical way to go. But for the Linux kernel, I am not sure it's the best solution.
Re: (Score:2)
kernels developers traditionally want very tight control over memory management. even with Rust you'll find that developers want to manually manage their allocations and have predictable and bounded behavior in the amount used.
Re: (Score:2)
Rust won't prevent security vulnerabilities... (Score:3)
... because the vulnerabilities stem from CPU design. The way pointers work on current x86 cpu's are the issue, and special secure processors that prevent you from accessing pointers directly and trying to attack and redirect program flow needs to be built into the processor and it costs performance.
So modern CPU architecture is mostly concerned with speed, and most companies are not going to break compatibility with an entire software ecosystem.
The whole problem is the way addressing works in most cpu's for most security issues. The rest of a lot of bugs are simply due to programmers not taking into account what variables or types will be passed or how much memory will need to be allocated because they aren't very good programmers. AKA predicting interactions with other programs at scale VS performance.
In the early days of DOS win 3.1 and fat 16/32 you had to worry about files not writing to disk sometimes properly and you needed to run chkdisk, that mostly doesn't happen on modern NTFS.
Re:Rust garbage (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The real issue is most people don't make effective use of the tools we have right now.
At work there has been a new push to turn on "-Wall --Werror" and we're getting resistance! Mainly from the lazy SOBs with thousands of (easily fixable) warnings in their code. We're also adding decent static analysis to our build pipelines but the idiots in charge are only checking for MISRA compliance. What's the point?
Effective use of the tools we hav
Re: (Score:2)
To be honest, I'm not a professional developer. I can write code, but definitely not an expert. I don't have a horse in this race, I'm just here for the popcorn. It didn't take long for me to find the first grumpy old man yelling at clouds.
My argument is that there are room for both: Better tools and better utilization of existing tools. I have spent too much time in my professional career trying to convince old fuddy-duddies that just because something is new and shiny doesn't make it inherently bad. I
Re: (Score:2)
Well, I am a professional developer of over 40 years, and I can say that most development teams consist of a mix of experienced and inexperienced developers. Some are good, some, not so much. I'll vote for more guardrails rather than fewer - not every development shop can afford to hire the best of the best across the board.
If you are reading this and you too are a developer, think about how many times you've written a non-trivial module and it worked perfectly the first time. For most folks, the answer
Re: (Score:2)
I have spent too much time in my professional career trying to convince old fuddy-duddies that just because something is new and shiny doesn't make it inherently bad.
Neither is something bad just because it's old. There is a lot of value in technology that is mature, stable, and understood.
I'll also add that it's almost always a mistake to start building on top of the new shiny. If web developers deserve any of the shit that gets flung their way, it's their bizarre need to constantly chase the latest fad, framework, or do-it-all library.
At that time, C++ was the "new shiny"
There were a ton of other hot new whatsits. You got C++ (my condolences) but what about the suckers who invested in Rexx or Delphi o
Re: (Score:3)
Can Rust help to make the Linux kernel safer? Linus and the lead kernel developers think so.
That is your interpretation. Mine is that Linus is giving them enough rope to hang themselves so they finally shut up.
Again you seem to be advocating that mistakes must be entirely due to idiocy. People making mistakes never enters your mind apparently.
Nope. That, again, is your interpretation. Obviously you have never looked at actual mistakes that caused real problems. A lot of them are utterly pathetic. Or you simply lack the skill and insight to recognize when somebody was incompetent. Here is news for you: In many cases it is glaringly obvious whether somebody had a clue or not. It is even more so when they explain to you (because yo
Re: (Score:2)
C is a small language the good book says, it's great for teaching people to program.
Re: (Score:2)
Re: (Score:2)
> People who complain about type-safe or memory safe code simply do not know how to write code well.
I don't know how to code well but somebody is foolish enough to pay me to code anyhow, so I'll use Rust to protect my sloppy ass and you can cry all the way to my fat bank.