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

[phoronix]

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

A six year old Linux kernel mailing list discussion has been reignited over the prospects of converting the Linux kernel to supporting modern C++ code...

https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss

[SteamPunker]

Wow, I did not expect that topic to be brought up for discussion again. Really curious to read Linus' eventual response to this. Have his strong opinions on this also evolved over time, also in light of the improvements in C++ over the years? I guess we'll find out soon enough. He was surprisingly open to permitting Rust code in the kernel, so there's that.

[ayumu]

Allowing Rust was a mistake.


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

[EvilHowl]

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.

[spicfoo]

While rest of the world moved on from C, Linux ecosystem has been continuing to write even net new projects in it. This is finally shifting in the last few years where there is a strong appetite to move towards something else. Typically that is Rust or C++ (and sometimes even things like Go where having a garbage collector isn't a blocker). Either could be a step up from C and it's good to see developers evaluating both even within the Linux kernel.

[SteamPunker]

Allowing Rust was a mistake.


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

That's the purist's point of view, being averse to any type of change, with the risk of sifling innovation.

There's nothing wrong with challenging earlier preconceptions, or reconsidering earlier decisions as technologies evolve and mature over time.

Are you that certain that Ritchie and Thompson got it absolutely 100% right for the rest of all time when they developed the C language half a century ago, and no better insights and improved paradigms in terms of programming languages would ever be developed afterwards?

[nvaert1986]

That's the purist's point of view, being averse to any type of change, with the risk of sifling innovation.

There's nothing wrong with challenging earlier preconceptions, or reconsidering earlier decisions as technologies evolve and mature over time.

Are you that certain that Ritchie and Thompson got it absolutely 100% right for the rest of all time when they developed the C language half a century ago, and no better insights and improved paradigms in terms of programming languages would ever be developed afterwards?

There's 2 sides to this. It's good to innovate and move to new things, because this helps humanity (and software) grow, yet there's also the risk of breakage and there's something which is know as "If it ain't broke then don't try to fix it". So far C (and of course C++) have really proven themselves to be stable and mature languages and could see this as a viable option. With rust on the other hand I'm not sure whether I fully agree from a stability perspective, yet do fully understand and agree with the the decision to allow rust in the kernel from a security perspective.

[cynic]

Are you that certain that Ritchie and Thompson got it absolutely 100% right for the rest of all time when they developed the C language half a century ago, and no better insights and improved paradigms in terms of programming languages would ever be developed afterwards?

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)

[dlq84]

Allowing Rust was a mistake.


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

You could always propose anything. Doesn't mean your proposal will be accepted, and this won't. Rust didn't change this.

[V1tol]

Allowing Rust was a mistake.


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

Rust at least has some features that can be usable for kernel. What advantage C++ has against C - 25 ways of initialization? Usually when someone says C++ is better than C is because they are looking at C codebase which is easy to understand and think - in C++ it will be even more readable. But then things escalate and you start using all that unreadable mess "for simplicity" and now your code nobody can read, not saying parse and understand. Any large C++ codebase is a great example.