Modern C++ is something nebulous. What is Modern C++ now would be obsolete few years down the line. So clearly maintenance of such a project wouldn’t be much fun, I suppose.

C doesn’t suffer from this for one. You have more time to focus on the task than on managing the myriad ways of doing the same thing.

Modern C++ is whatever is standardized and implemented. Obviously, as new Standards are published, new features become available, and any workarounds for their lack become redundant. But that has not inconvenienced SerenityOS even a little bit.

It can be reduced to actually writing proper C++ instead of C with a C++ compiler, already that basic change is quite modern for many folks.

First, C++ has changed SIGNIFICANTLY since then. Second, Linus is wrong.

C++ did not, strictly speaking, exist at that time. I.e., there was no Standard defining it, and most of what makes it useful was not implemented in compilers.

About all proto-C++ had that was actually useful and usable, beyond C, was destructors. That changed by around 2003.

So it was much less mature than even Rust is today.

Yes, when Linus first tried C++ in 1992 this is true. But the linked comments were done in early 2000s which by then C++ was very mature. So by early 2000s, C++ was already 20 years old. Rust is only 11 right now.

Yes, Linus is just full of crap, on that topic.

But Rust is more mature now than C++ was in 2007. Fully self-contained projects can move fast.

The irony is that many of the complaints apply to Rust as well, even if in another way.

Just wait when the first set of monadic libraries full of macros start landing on Linux drivers.

I am quite sure Linus won't be amused, but hey at least it isn't C++. /s

2011 is late? Or are you referring to OSes in general?

Any C program, including an OS kernel and its apparatus, can be transitioned seamlessly to C++ in a day, and then modernized at leisure. Ten years is plenty of time for that.

From an old FAQ page[1] for TauruOS:

> I wrote ToaruOS at a time when I was much more competent at C than C++. I still think that's true. At this point, the effort of rewriting datastructures to make use of C++ functionality would not be a good use of time - and writing userspace code in C++ in ToaruOS-NIH is not yet possible as I have yet to get a C++ standard library set up.

1: https://github.com/klange/toaru-nih/wiki/FAQs

This is sooooo not true. It might compile with a C++ compiler but they're two entirely different langs and the best code looks very different between the two.

Plus, C++ requires extra setup at the kernel level given the init code. It also requires manually designing your vtables.

Also, verifying C (if you ever go that route) is many times easier than verifying C++.

Also C compiles faster in many cases, easing development.

Plus C doesn't bark at you about certain ASM-isms that are frequently found in kernel code.

Plus C is arguably easier to reason about.

Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

Plus you're doing a lot of init work that never returns thus automatic destructors aren't as useful.

Also C is just fun, and perfectly suited for the task.

> Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

https://github.com/microsoft/wil

"Ah, but that isn't used on the Windows kernel" would be the expected reply, well

https://community.osr.com/discussion/291326/the-new-wil-libr...

"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)

But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."

That's not practical in every case, and that's not the standard library. It's a subset of it. I never said you couldn't do your own.

No language uses the standard library on the kernel, not even C.