Rust in the Linux kernel: part 2

The two most important/ prestigious universities here, Oxford and Cambridge as I understand it both teach an ML as First Language, teaching Rust would arguably qualify (Rust is basically an ML but with spelling familiar to a C or Java programmer) but with the caveat that one reason they teach an ML first (and indeed so did the place where I got my degree) is that some of the 18 year olds in your class know C or Java or indeed Python, but they almost certainly do not know Ocaml or SML or whatever - whereas they might know Rust.

And that sort of gets to where your parent was thinking. On the whole it's not that university (or "college") teaches Rust, but that because Rust is a good first language some people will have just acquired Rust anyway. I came to Rust as somebody with decades of C and Java and some Python, Go, and a long list of languages, but today plenty of learners just pick up Rust themselves.

Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.

Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.

> I’m assuming the goal is to have the entire kernel rewritten in Rust.

Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.

> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.

If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.

It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.

The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.

The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.

> manual memory management, manual layout control, and manual resource management to retain similar behaviors.

All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).

Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.