Only on Linux due to Linus religious hate more specifically, C++ managed alright on Windows, macOS, BeOS, Symbian, GenodeOS, Mbed, Android Treble drivers, Arduino, AUTOSAR.
I wouldn't say Windows drivers were C++, more like "C with Classes" (and maybe a little bit C++)
Also, Windows drivers are usually much more convoluted than Linux drivers https://github.com/microsoft/Windows-driver-samples
Anything that uses 1% of C++ specific features is C++.
C as used by Linux kernel is not ISO C, yet no one argues it isn't C.
Technically correct and this raises an important point. How long would the kernel take to compile in C++ versus in C?
Though in practice if you think the kernel should support all the craziness of "modern" C++ you're going to have a big problem in making it work in kernel space. (things like heavy templates, etc)
And just to disagree with Linus I think the 'new' part is the least of our problems in making the kernel work with C++
As for compilation times, it is all a matter of how the build system is architected.
Most of my C++ build pipelines compile faster than Rust, in make clean all scenarios.
There is no black magic in how to achieve it, just knowing what one is doing, making use of binary libraries, build caches, and be aware of how much craziness is allowed, most of which wouldn't be allowed on the kernel anyway.
How to do this is surprisingly easy: write small crates that do 1 thing.
A Rust crate is a C++ TU, pretty much everybody that complains that Rust is slow is comparing Rust crates that are 10-100x larger than the size of the .cpp files they use in their C++ projects.
For some reason, people, and particularly C++ devs, like to write huge Rust crates (I’ve seen crates with 200k LOC). They’d never write a 200k LOC .cpp file, so I really don’t get why they do this.
Either way, if your Rust compile times are slow, it’s probably your and only your fault.
How to get blazing fast Rust compile times isn’t a secret.
We have a lot of data of the time it took to compile C++ TUs vs the equivalent Rust crate, and Rust reliably compiles at least one order of magnitude faster, sometimes two.
All our crates are less than 10kLOC, median is 1812 LOC.
Rust crate binary compatibility is also pretty awesome, so that in general a new hire does not need to compile anything at all (an unmodified build just fetches binary objects from sccache). When they start modifying the project, only those binary objects that actually changed have to be recompiled, the rest is just dynamically linked. This gives you <5s edit-compile cycle if you are working on a leaf crate.
If your C++ compile times are slow, it’s probably your and only your fault.
It also supports unity builds, and C++ modules TS, so we can compare the performance of all 3 approaches
Rust consistently beats all of them by at least an order of magnitude in apples to apples comparisons, with at least an order of magnitude less fiddling in terms of modifying the source code, fiddling with build system and compiler options, etc.
So in our experience, Rust gives you 10x faster compile times with 10x less effort than C++ if you use similarly sized compilation units.
Rust makes it easy to write compilation units that are 10x-100x faster than C++ ones and still compile reasonably fast for their size, but we don’t allow this by convention (we have a clippy lint that rejects crates that are too large).
So do you also have something comparable to Incredibuild and Clearcase derived object files in place?
We supported them for a while (until 2015 or so; no perf difference over 3 years), but Clang modules gave the exact same perf and was easier to use, and unity builds were much faster for clean builds anyways, so there was no point in maintaining PCH in parallel to these two other options.
For people that are not aware, PCH, modules, etc. bought us 20-40% compile time reduction. I expect 30% or so to be typical for projects that are using TUs correctly.
A 30% compile time reduction or even a 2x compile time reduction is not “life changing”. It’s peanuts.
Particularly compared with the 10-100x compile time reductions that Rust gives you. From 100min to 1 min, that’s a huge difference. From 100 min to 50-70min? That’s an irrelevant difference.
If you think a simple tautology disproves someone's claim, there's a good chance you're missing the point.
One can endlessly discuss pros and cons of using C++ in the Kernel, but in the end it's about either making a bet on C++ or not; it's not that one can or has to formally prove that the bet is right to avoid being called religious. Linus listed cons that he finds important (which are real) and decided not to bet on C++.
Linus has a long history of successfully managing Kernel, I think this makes his bets worth something. So yes, passing Linus filter is a great success for Rust, and even greater given that C++ didn't pass.
Also, the fact that C++ succeeded somewhere doesn't disprove this claim.