Will there be performance and security improvements?
Memory safety would be the main advantage.
It’s a better, more modern language in general. It has way better tooling (better, more user friendly compiler, better package manager), really good set of modern features (null-safety, good error handling, type-classes, algebraic types), it’s easier to modularize your code (workspaces, modules). Rust does a lot of things right and is fun to work with. That’s why it’s the most liked language overall. It’s not hype, it really is that good. It will just make working on the kernel easier. And on top of that it offers some memory safety and concurrency features.
P.S. I forgot about amazing documentation. Again, way better then what you can find for C.
P.P.S Zero cost abstractions.
The “tooling” argument is kind of backwards when we’re in the kernel. The package manager is not allowed to be used. Even the standard library is not allowed to be used. Writing code free of the standard library is kind of new in the Rust world and getting compiler support for it has been one of the major efforts to get Rust into the kernel. Needless to say tools around no-stdlib isn’t as robust as in the user world.
Not true, you can use cargo to build Linux drivers: https://github.com/not-matthias/kernel-driver-with-rust/blob/master/Cargo.toml
That link appears to be for a Windows driver.
Ups, you’re right. Still, better tooling attracts more devs to a language increasing the number or people that in the future may work on the kernel and in the future it could be possible to build Linux drivers using cargo. So yeah, today it’s not that important but it still a benefit.
I’ve been watching Asahi Lina develop a big GPU driver for Apple silicon and development was so much faster because a whole category of bugs were largely absent once the code compiled, and memory issues are notoriously difficult to fix. Also error handling is easier and much cleaner.
Security? Probably. I wouldn’t expect any measurable improvements to performance but the with compiler being able to do more checks it might enable some clever optimization trickery that would be harder to maintain in C.
Still, Rust on the kernel probably won’t leave the realm of drivers any time soon, so it all depends on if you have the hardware that will use a driver written in Rust.
Memory safety is likely to prevent a lot of bugs. Not necessarily in the kernel proper, I honestly don’t see it being used widely there for a while.
In third party drivers is where I see the largest benefit; there are plenty of manufacturers who will build a shitty driver for their device, say that it targets Linux 4.19, and then never support/update it. I have seen quite a few third party drivers for my work and I am not impressed; security flaws, memory leaks, disabling of sensible warnings. Having future drivers written in rust would force these companies to build a working driver that didn’t require months of trawling through to fix issues.
Now that I think about it, in 10 years I’ll probably be complaining about massive unsafe blocks everywhere…
Performance? Not really no. I believe C is slightly faster with Rust and C++ competing for second place. The benefit is safer code as Rust is built with performance and safety in mind. It highlights what potential errors can be found where making human error way less common. Instead of potential null errors types are wrapped in an option enumerator which ensures you know there can be a lack of a value. Expections are also enumerators done similarly with a result object so you know which functions may fail. Instead of using memory and potentially forgetting to free it we have the ownership system.
How is C faster than C++? Unless you use virtual functions, it’s as performant as C. And you definitely wouldn’t use virtual functions in a kernel.
C++ is only as fast as C if you use only the parts of C++ that are identical to C. In other words, C is faster than C++
That’s just plainly false. A
std::sort()for examples beats aqsort()easily. C just doesn’t have the tools to handle that kind of thing without a lot of manual code duplication.The reason for not using C++ is simply that it’s a huge monster of a language, that makes it difficult to find common ground for a programming style. In C that is much easier as you have much less features to worry about. It is more verbose and error prone, but also more predictable and easier to review, as the code you see is what you get in the binary. In C++ can have a mountain of stuff hidden behind operator overloading, exceptions and other stuff, which makes it very difficult to reason about.
Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.
The fact that the implementation of one random
std::Sortis faster than the implementation ofqsort()is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously theqsortyou are referring to.I am certain there are sort implementations in C which outperform Rust.
Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).
You can use compile time polymorphism in C++ without any runtime performance cost.
Unfortunately, that’s not true
The description says:
In this video, we’ll do a deep dive on what C++ Polymorphism is, what “virtual” does under the hood, and ultimately why it is SUCH a performance hit compared to languages like C and Rust.
This is not about compile-time polymorphism.
The use of basic classes can very quickly become a performance issue because of data locality issues, confusing the branch predictor, and generally using instructions where C wouldn’t need to.
They’re honestly insignificant compared to the value you get in return, especially with the better typing and application design, but they’re there.
If you stick to the builtin classes, no capturing lambdas, don’t use too many generics, and use
constoften enough, you should be able to produce code that’s as fast as C. At that point you may as well use C, though, especially because one mistake with semantics and you’re back to hitting C++ related performance issues anyway.
Yes, enhanced security is pretty much the entire pitch of Rust. There wouldn’t be any reason for it to result in performance enhancements, though.
There are theoretical performance improvements possible by compiler optimizations if the guarantees Rust provides are met. However, the kernel relies on a lot of
unsafecode to interoperate with C so I don’t expect that to actually happen, because all of the safety guarantees go out of the window the moment you use that keyword.Well, it largely removes an attack surface for memory bugs, which is a huge thing. If we’re writing a big driver (see the Rust driver for the Apple GPU) then suddenly waving hands incoherently 90% or more of the driver (depending) is likely to be much more memory safe and stable. As has been demonstrated with that particular driver already.
I was watching the streams and when it compiled Asahi Lina usually only had to deal with logical type errors, not memory issues, it was basically a great showcase for Rust and memory safely. Unsafe is perfectly fine Rust, but it’s a contract where the developer says to the compiler: “I know you can’t guarantee this block is safe, so I’ll keep a special eye on that, peer review more, test, etc. while you keep an eye on all the other code I can’t fit in my head”. In the case of Linux an Unsafe blocks means “we’ll trust the Linux kernel code we connect to, though review it carefully”.
So saying all safety goes out the window is wrong, see it as a vastly reduced potential for memory problems, better error handling and more stable drivers, as demonstrated by the Apple GPU driver.
Rust code calling Rust code definitely brings safety improvements. The problem is that a lot of Rust code also needs to interact with C code (to work with pointers, for example) and that’s where
unsafebecomes a requirement, and where the compiler’s optimizations don’t get applied automatically anymore.Unsafe Rust code in the kernel is as safe as the existing C code because unsafe code is the norm, and that’s why Rust only makes things safer. However, in terms of performance improvements alone, you need to have in-depth knowledge of what abstractions you can or cannot use, and
unsafecan make a bunch of easy automatic optimisations stop working.
