From my memory of Linus's C++ comments, they basically boil down to "the kernel needs to do everything in freestanding mode, and everything that's interesting in C++ is not in freestanding mode, so what good is it?" (plus some ranting about "zero-cost" exception handling being rather more expensive than its name implies). In general, a strong vibe of someone who tried C++ in the early 90s, gave up on it then, and is generally ignorant of how C++ is different from back then.
If Linus's first introduction to C++ was to C++11, I'd imagine his opinion of C++ would be higher (probably not high enough to permit it into the kernel, though). To a large degree, Rust is "take the good new parts of C++11, strip out some of the legacy insanity, and let's also work out how to keep as much of the good stuff in a freestanding environment as possible." Which answers a lot of the objections that Linus had to C++!
We still don't have all of the interesting C++ features in freestanding mode. It's still a fairly unknown component of libc++ and libstdc++. I've only been playing with it recently because I was curious about how many of the c++17 and newer compile time features I could get to work in avr-g++.
There was also the epic quote about how keeping out all the C++ programmers was enough of a reason.
Which is funny, because you can see the truth to it. With C++ comes endless debates. No technical reason really, but a social one, and so far the Rust culture seems to be closer to C in that regard.
As someone that started with C++ on MS-DOS, back when 640 KB would be enough for everyone, there is plenty of stuff in C++, making it better than C even in kernel space.
That is why contrary to Linus opinion, Symbian, IBM z and IBM i, Windows (since Vista), GenodeOS, and OS X, have C++ running on their kernels even if it isn't the full blown language.
Additionally many of his criticism against C++, applies equally well to Rust, in terms of language complexity, just wait until some kernel driver go crazy with macros or FP inspired designs.
What is indeed a plus for Rust is the secure code mentality that both C and C++ communities have kept downplaying until companies and government had enough with burning money fixing exploits.
True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn.
Note that I'm not saying Rust is easy to learn. I found it to be so, but it's going to be different for everyone. I do firmly believe that it's far easier for the average dev to learn the core of Rust than the core of C++, with far fewer footguns along that path.
This problem is (so far) solved by the editions feature. Breaking changes can be made to the language without splitting the ecosystem (like python 2 vs 3).
Rust has a 6 week release cycle and a big complaint is that the language isn’t changing quickly enough so there is pushback from both ends to take into account here. My take is that there are only hard problems still to be solved given that that they need to be solved in a zero cost way.
From my memory of Linus's C++ comments, they basically boil down to "the kernel needs to do everything in freestanding mode, and everything that's interesting in C++ is not in freestanding mode, so what good is it?" (plus some ranting about "zero-cost" exception handling being rather more expensive than its name implies). In general, a strong vibe of someone who tried C++ in the early 90s, gave up on it then, and is generally ignorant of how C++ is different from back then.
If Linus's first introduction to C++ was to C++11, I'd imagine his opinion of C++ would be higher (probably not high enough to permit it into the kernel, though). To a large degree, Rust is "take the good new parts of C++11, strip out some of the legacy insanity, and let's also work out how to keep as much of the good stuff in a freestanding environment as possible." Which answers a lot of the objections that Linus had to C++!
That's also in line with my memory of it.
We still don't have all of the interesting C++ features in freestanding mode. It's still a fairly unknown component of libc++ and libstdc++. I've only been playing with it recently because I was curious about how many of the c++17 and newer compile time features I could get to work in avr-g++.
And the answer is ... not much.
I've been spoiled by Rust's "core" crate.
There was also the epic quote about how keeping out all the C++ programmers was enough of a reason.
Which is funny, because you can see the truth to it. With C++ comes endless debates. No technical reason really, but a social one, and so far the Rust culture seems to be closer to C in that regard.
As someone that started with C++ on MS-DOS, back when 640 KB would be enough for everyone, there is plenty of stuff in C++, making it better than C even in kernel space.
That is why contrary to Linus opinion, Symbian, IBM z and IBM i, Windows (since Vista), GenodeOS, and OS X, have C++ running on their kernels even if it isn't the full blown language.
Additionally many of his criticism against C++, applies equally well to Rust, in terms of language complexity, just wait until some kernel driver go crazy with macros or FP inspired designs.
What is indeed a plus for Rust is the secure code mentality that both C and C++ communities have kept downplaying until companies and government had enough with burning money fixing exploits.
True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn.
Note that I'm not saying Rust is easy to learn. I found it to be so, but it's going to be different for everyone. I do firmly believe that it's far easier for the average dev to learn the core of Rust than the core of C++, with far fewer footguns along that path.
Oh I don't disagree with any of that, I like Rust. I was just surprised is all.
C++ was also tiny 40 years ago, just give it 40 years as well with the current six months release cadence.
This problem is (so far) solved by the editions feature. Breaking changes can be made to the language without splitting the ecosystem (like python 2 vs 3).
https://doc.rust-lang.org/edition-guide/editions/index.html
Rust has a 6 week release cycle and a big complaint is that the language isn’t changing quickly enough so there is pushback from both ends to take into account here. My take is that there are only hard problems still to be solved given that that they need to be solved in a zero cost way.