Rust Is Going To Destroy The Linux Kernel!!!

This is this fear that rust is going to destroy the future of the Linux kernel but many are heavily in favour of it's introduction, I'm not a kernel developer so let's hear 2 polar opposite opinions and make a decision for ourselves

==========Support The Channel==========

==========Resources==========

=========Video Platforms==========

==========Social Media==========

==========Credits==========
🎨 Channel Art:
Profile Picture:

#rustlang #rust #Linux #OpenSource #FOSS #linuxkernel

🎵 Ending music

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.

[HaniiPuppy]

Implying that Linus Torvalds would be one to just cave in and accept a major change to the Linux kernel to avoid confrontation is the ridiculous height of delusion.

[notjulesatall]

It seems that Lina did the effort to *use* Rust and provide a case that illustrate the benefits of Rust for a real life kernel dev case. On the other hand Drew is just doing fearmongering without ever doing the effort to provide facts to support his claims.

[AmirHosseinHonardust]

The thing about memory safety and rust is that it is not about bringing memory safety to the already well performing C code of the kernel, but to future codes to be added.

[miguelguthridge]

The whole point of Rust is that it forces you to handle the edge cases. I've heard a lot of people claiming that rust is a language where "if anything goes wrong it crashes", but that simply isn't true - it only does that if you choose to make it do that, which a kernel developer definitely shouldn't. The other great thing about it is that this makes all the places where it can panic very explicit, and all you need to do to find them is search for unwraps and panics.

[gpaulu]

I think its worth keeping in mind that Rust in the kernel will start as experimental and optional.

[mrpocock]

Kernels and drivers are exactly the sort of code where Rust is what you want. There are edge cases where you may take a performance hit relative to c, but there are just so many bugs you can write in c and never even notice that can't even be expressed in rust.

[jacobzimmermann]

This is a textbook example of Poe's law: there is always a point where it becomes impossible to distinguish parody from reality. The anti-Rust crowd got there very quickly indeed.

[miroslavstankov]

I'm not nearly knowledgeable enough on the subject to actually form my own opinion on whether Rust will be beneficial or detrimental. I can only say that I hope Linus knows what he's doing and that it all turns out well. Also, wanna feed the YT algorithm.

[SArthur]

"I will not re-open the memory-safety flamewar, so we will assume these (dubious) things" This is called poisoning the well...
Furthermore, if memory safety is a point on your list, surely it is worth discussing in depth. If you're going to write an article about it, you can well go ahead and honestly express your own point of view.

Edit: case and point: later in the article, he talks about risks and carefully evaluating them. Memory issue risk management is precisely one of the arguments in favour of using Rust.

[Speykious]

There are lots of people making the argument that Rust is not adapted to kernel/driver development because you have to use `unsafe` everywhere. Problem is, they think that `unsafe` turns Rust into some kind of C and are not aware of what it truly means.

If you want to know more about `unsafe` in Rust, there's a good conference from Jon Gjengset titled "Demystifying Unsafe Code". It only gives you 5 additional permissions and there's still a lot of guarantees that you have to provide.

[classicrockonly]

I think this will be one of those “only time will tell” things. Will building workflows become to cumbersome? Will there be any other unseen side effect? Will it all be not as big of a deal as some think?

[glkraken]

As a dev who likes and uses rust, I'm happy of Rust going into the kernel.

[PhilKulak]

As a die-hard Sway user, I love Drew, but Lina is the one doing the actual driver work.

[juliuskoskela]

As someone pretty fluent in both C and Rust I can tell that both had strong opinions on Rust, but only one had used it and had a proper idea about it's benefits in comparison to C. The analogy at the end is very apt.

[SimGunther]

No casual user will care about the implementation of any software until it hinders their experience. If that were the case, we'd already have mainstream operating systems written in Haskell, LISP, Smalltalk, or Rust a LONG time ago.

[affegpus]

I feel that there is a lot of feelings related to some people that thought they would kept codin' forever

then one day they found themselves watching a japanese cartoon girl coding a kernel driver on stream on a low level fast language that somehow ensured memory safety, and then they realized are not in "it" anymore and what is "it" now confuses and scares them.

Mixed with their opinions about Rust in kernel.

[AmirHosseinHonardust]

It is also worth considering that the trendiness argument for rust is put forth by Linus himself.

[alancrobertson]

I'm just sick of buffer overflows being the number one reason for all hacks. I don't care about C or Rust being used in the kernel - either replace C with Rust to stop this or make C compilers do the job that Rust is already doing. Either way the hacks go away. e.g The recent Sudo heap based buffer overflow. Come on guys this is Sudo - if you can screw up that then you can screw up anything. How many people looked at that code over the years and never noticed?

[theosexpertdaymon]

As long as the kernel is stable and doesn't bloody crash I couldn't care less.

[vanlepthien]

Thinking about the errors I've had to fix in C that are addressed in Rust, once one thinks in Rust, coding complex kernel code should result in faster code development and better code.
I haven't worked on the Linux kernel, but I used to write drivers for and modifications of IBM mainframe (S/370 - S/390) OSes in Assembler.