C++ has implicit allocation and Linus doesn't like that, for good reason. While it's amusing to imagine trying to "ban all the stuff you don't like" when that means core language features, it is not a realistic plan.

In Rust, allocation lives in a library, alloc, and so the Rust for Linux project did all the work to offer alloc (it's full of useful stuff and it isn't like the Linux kernel can't allocate memory) but without implicit allocation.

If you use Rust to write say a Linux command line program, you can write

  greeting += " and welcome traveller";

... and of course implicitly this is an allocation, 'cos it's not like this greeting variable just magically already has enough space to append a string. But in Rust for Linux, you can't do that, the implicitly allocating += operator is not provided on this type in their alloc library. If you want to say "Allocate more space for the greeting" you can do that of course, just as you can today in C but you must do so explicitly and so when you try to add 16GB of extra string space because you're an idiot, the API you had to explicitly call gives you an error and that's your problem.

However the most critical reason Linux doesn't have C++ is that C++ proponents didn't do the work. Now, that will probably be because "reform the entire language to suit Linus" wasn't a viable plan, but the fact is that Linus can't accept patches that nobody writes, so even if you're sure C++ would be viable without drastic changes, you didn't write the patchset that does it. Likewise if people don't send Linus patches to do C11 it probably won't happen.

> C++ has implicit allocation

Ah, but see, it doesn't. Linus was wrong about many things in his rant. This being one of them.

Now the standard library does indeed have things that do implicit allocations, such as std::string. But these, like with Rust, are distinct from the language & replaceable. Would it be effort to make a kernel-safe std:: replacement? Yes. Would it be a lot of work? Not really. And it's the kind of thing Linux has been doing for decades with C anyway. It's not like they use a standard libc implementation (much less a rich libc implementation like glibc), for example.

And it's something game devs have been doing with C++ for decades without any issues, too.

So for this one you don't even have to ban anything. Just don't pass a standard library implementation to the compiler. It doesn't come with one, after all. You have to add it. So you could just... Not do that.

As for nobody did the work... That's true. But Linus also pretty much nuked the entire concept of using C++, regardless of the what or how. Time seems to have changed his mindset on some of those things, hence his reaction to Rust, which largely makes all this moot. But we shouldn't confuse short term politics with technical issues, either.

> Linus was wrong about many things in his rant. This being one of them.

Its not what is being discussed here. C++ has an implementation defined memory model. That just cannot work with Linux out of the box. You need an OS and compiler designed from the ground up to handle this.

C++ has a well defined memory model: https://en.cppreference.com/w/cpp/language/memory_model And it's not that different from the C memory model. How did Linux work with C?

> C++ has a well defined memory model

Only since C++11, and it's not a full blown memory model.

C++ has with a close, approximation, the same memory model as C, both concurrent and otherwise. In fact C11 just adopted the C++11 concurrent memory model wholesale.

it's defined enough for C to have adopted it since C11 (https://people.mpi-sws.org/~viktor/papers/cpp2015-invited.pd...)

Arduino, ARM mbed, Symbian, macOS, Windows, BeOS, IBM i and z/OS accepted the work of C++ proponents.

There is nothing when can do to change political views.

And lets not pretend that Rust in the kernel won't suffer from creative uses of macros, and there is still a big laundry list of issue to fix before it actually makes it.

Or that for the time being, Rust compilers need to link to C++ code to actually work, at least until Cranelift is a match in code quality against LLVM or GCC.

So in the end Linus gets C++ into the kernel, even if indirectly.

> Rust compilers need to link to C++ code to actually work

GCC itself has been written in C++ since 2010.

Indeed, which kind of diminishes Linus's assertions against C++ even more.

Its notable that the main improvement over gnu98 C to C11 essentially templates, if a worse version of it with better compile time performance.

If they switched to c++17, and banned everything from throw and RTTI to the standard library, they would still get for each, auto, and templates and inheritance which does not have to be emulated in C.