| It’s actually sort of interesting why Linus has basically closed the door on C++ ever getting into the kernel, while Rust seems to have gotten the green light. If you look at Linus’s initial reasoning [0] (which was from a long time ago, nearly 20 years now, way before C++11), it was because the abstractions it offered/encouraged could make it hard to reason about what’s really happening, which may be bad for kernel code, and that allowing C++ would open the floodgates for C++ programmers to contribute, and Linus famously hated C++ programmers. Rust-in-the-kernel came up many years later, and IMO if Linus was really honest with himself he’d either (1) not allow rust for essentially the same reasons he disallowed C++, or (2) admit his views have evolved, and say that C++ should be allowed on the same tentative basis that Rust is. I get that rust offers safety advantages that C++ doesn’t, but I don’t think that’s the complete picture… modern C++ offers so many of the same advantages (although obviously not all) that if we’re really being honest with ourselves, it would seem to be unfair that Rust is let in while C++ is not. Both of them are enormous steps up in safety over C. [0] https://harmful.cat-v.org/software/c++/linus |
I would argue one (Rust) is, but not C++. Rust is more "batteries included" and doesn't require specific compiler flags or complicated tooling, it just works and gives you guarantees out of the box. C++ seems to allow escape hatches by default while Rust requires you to call that out via `unsafe`.