A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++

[rene]

20 years later some kernel devs finally come to their senses! Congratulations. Can't wait for a more type safe and higher performing kernel!

[zcansi]

Happy if this causes the kernel to move towards requiring more up to date toolchains. In the year 2024 we have great open source cross compilers, there is no good reason to be held hostage to ancient or proprietary toolchains, especially when the people who use them don't pull their maintenance weight.

While I like Rust, I'm not sure it will be a slam dunk success for an existing kernel with long established ways of doing things. I just hope it gets a fair shot either way.

As for C++, I have no strong opinions about it as long as the kind of C++ being used is tightly policed and care is given to developer experience (i.e. error messages that are helpful).

[Zeioth]

Allowing Rust was a mistake.


Now, Linux is left wide open to this sort of proposal.

Rust is a good language. The thing is it was released in 2015 and it is still relatively new. The strongest case for Rust is that eventually is gonna replace C in universities because it covers its case of use and does it better.

More devs = more contributors.

Trying to predict the future is always risky. But if the newest features come with the memory safety of Rust. That's less people focused on QA that.

Also, given the amount of C programs out there, there is 0% chance C is gonna dissapear during the next 100 years or so.

[mb_q]

So they want C++, especially C++20 to make kernel macros easier to maintain? Then again Rust is a better idea since it has both better macros than C++ and many kernel DSL-alike uses can just be done with traits. And modern Rust is like 2 years older than C++20.
Sure, C++ is a best option to make some unholy mixture of code representing all the paradigms in the last 50 year history of imperative coding, hence making everybody "feel at home" at some point, but is it a good idea?

[Setif]

IIRC, Linus himself was strongly against C++. I don't remember what bad words he used to describe C++.
OK I found it https://harmful.cat-v.org/software/c++/linus

[cj.wijtmans]

C++ is literally the same tool chain, i only see benefits with this. And as said some C++ features can and will be left out for obvious reasons.

IIRC, Linus himself was strongly against C++. I don't remember what bad words he used to describe C++.
OK I found it https://harmful.cat-v.org/software/c++/linus

A LOT has changed since 2007.

[yoshi314]

I completely agree. Just like they are already using a subset of the C11 standard, Linux could migrate to a subset of modern C++. They do not need to use OOP, exceptions or RTTI if they don't make sense in the context of a kernel, but substituting the insanely bug prone macros of C with safer template metaprogramming and concepts will make it easier to program less bug-prone code.

SerenityOS currently uses a very unique style of modern C++ programming with a custom standard library and it's a joy to contribute to it.

I hope Linus' opinion on C++ has changed in the last twenty years, because C++ has become a much different (and better) language since then.

that is also the problem with c++, it's an ever-evolving language. you can really write obtuse complicated meta-spaghetti code with it, with what it already has to offer. ( and i only know templating and oop, i bet there is plenty more)

That and i think debugging might require a bunch of new tools. I've heard some programmers say that assembly is easy to trace back to specific line in C code. with C++, things may get more tricky.

There is also an issue of potential lack of compiler for a given new platform or issues porting/backporting patches as c++ standards will shift across kernel versions. it's so much faster/easier to provide a C compiler than a C++ one. but maybe with modern tools it's not so bad.

[ddriver]

I am looking at "modern c++" and I am thinking:

This has almost everything I wished it had 15 years ago. And somehow, they managed to expose it in the most verbose, convoluted and obstructive way possible.

Ironically, bleeding edge c++ still can't do some of the stuff trusty old macros have been doing forever.


It is it not my business to manage their code base, but if it was, I wouldn't allow it ever. KISS

[mmstick]

what they got wrong with C has been fixed by Thompson himself in Go.

(not saying that Go would suite the development of a kernel, I'm just answering your specific question)

Your comment gave me a good laugh. Not only is Go not a suitable replacement for C, it makes many of the same mistakes, and adds some new ones.

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

Go is not even in the same class as C, C++, or Rust for the mere fact that it automatically spawns a multi-threaded async runtime with a runtime garbage collector, and spawns everything before the main function. Compare to Rust, where automatic garbage collection with a runtime is neither necessary nor sufficient. It has an expansive open source ecosystem where you can choose to opt into any allocator or async runtime of your choice.

Ironically, even though Go is a language touted for its concurrency with goroutines, it has an astonishing lack of thread safety features.

[JEBjames]

@Michael

Typo?

"Jiri Slaby of SUSE Lans" should be Labs?