Initial Support For The Rust Language Lands In Linux-Next

[Guest]

It is going to be a long long long time before any significant number of drivers would be rewritten, but this will allow newer drivers that are intended to run on the (currently supported) arm64 and x86_64 architectures to be written in rust in the future. Anything that potentially lowers the barriers to entry for development and ongoing support of new/additional hardware should be considered goodness to the Linux ecosystem.

True, for example any WMI drovers for newer hardware could be written in Rust. That stuff is usually small.

[Filiprino]

And when will C++20 or later be allowed into the kernel? It's time to move on. At Google are using C++ for their Fuchsia microkernel. BeOS, EROS and L4ka also use C++. If I was to criticise C++ I would point to the template system and name mangling, which are minor drawbacks compared to having OOP built into the language, among other things. Then you have static analysis and dynamic analysis tools. Valgrind, etc. Maybe the kernel lacks a proper test suite to capture memory leaks.

The last notable comment on C++ I have read from Linus Torvalds dates back to 2004. He said STL and Boost are crap. Like if you were going to use the STL in the kernel And continued to add that you get projects to depend on nice C++ abstractions and then you figure out the abstractions are not efficient and you have your whole project depending on those abstractions and then all becomes crap here and there. Crap everywhere.

There is a long path between limiting yourself to the C feature set and bloating your project with external dependencies, something Rust brings with its Cargo "bullshit loading system". Ironically, he never mentioned memory safety, something which C++ improves on, too. A college student from the 80s could only use a non-standardised C++, which seems to be the C++ version he used.


And that's my rant about introducing more languages in the kernel toolchain which will increase complexity. More languages == more toolchains/interactions == more bugs.

This decision to me seems random and not justified, based on subjective or corporate choices. Personal taste.

[ssokolow]

This decision to me seems random and not justified, based on subjective or corporate choices.

Last I read, C++'s abstractions still tend to rely on language features that would be forbidden in the Linux kernel regardless of language, like exceptions. Also, Modern C++ Won't Save Us (by Alex Gaynor).

C++ was one of the languages Rust's design learned from, which puts it in a better starting position for being suitable.

...and you don't have to use Rust with Cargo for it to be useful. Cargo is definitely valuable, but it's like those C++ features not suitable for kernel development... just a highly desirable convenience for userland coding.

[Filiprino]

Last I read, C++'s abstractions still tend to rely on language features that would be forbidden in the Linux kernel regardless of language, like exceptions.

Rust is no different with Panic! and Result<T,E>. Disable exceptions and use <system_error> and <cerrno>. On the other hand, Linux already does stack unwind to print backtraces. Adding exception support is a matter of adding more libraries to the build system: RTTI and stack unwinding (already present).

Also, Modern C++ Won't Save Us (by Alex Gaynor).

That's why lifetime checking and RAII exist. C++ lifetime spec is less verbose than Rust's. Once it is finalized it will be more practical. Rust adds an "exclusive write reference" constraint. I think for the data race warranty in multithreading.

C++ was one of the languages Rust's design learned from, which puts it in a better starting position for being suitable.

C++ designers do learn, too. C++ keeps evolving and every new added feature has to go through a standards committee. I don't think either language is in better position than the other. But I prefer a standards body. Added features are rock solid and ready for implementation.
In addition, every implementation is free to add their own extensions. GCC has plenty of GNU extensions. They could implement lifetimes already, as is the case in MSVC and Clang. But for some reason no one is willing to experiment with GCC, not even Linux developers who seem anxious to add something better than C to the kernel.

...and you don't have to use Rust with Cargo for it to be useful. Cargo is definitely valuable, but it's like those C++ features not suitable for kernel development... just a highly desirable convenience for userland coding.

But it's strongly promoted, which falls into the same category of "abstractions" you are not supposed to use in a kernel.