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

[darkonix]

It's just a shorthand for saying I do not like the change. I code in C not C++, and have no intention of learning that god-awful mess of a language. No I don't contribute to the kernel. I do read bits of it from time to time. At least part of my interest in the Linux kernel is that I can understand it.

Oh, I just thought that you were quoting Leonard Nimoy's song Highly Illogical and I completed that verse. Sorry about the confusion.

[anarki2]

I leave you with the classic joke:

return C++; // makes C bigger, but returns the same value

[Veto]

The irony of the Linux kernel adopting a CoC when their founder is infamously taped flipping off the camera and saying fuck you to Nvidia.

Well, Linus has also famously apologized for his past behaviour and took a break from development to seek help. I see no irony in maturing, getting wiser and working actively to improve. Neither people nor code should stagnate.

Of all of Linus' infamous rants, I think the Nvidia bird-flip is rather innocent and non-personal. If you watched the video he actually sort of apologized to a Nvidia employees in the room after he had expressed his unequivocal opinion towards Nvidias kernel cooperation.

[ssokolow]

That is correct. Go has a distinctive C influence. Whether this is good or bad depends on what problem you are trying to solve. Go and Rust are both successful languages with growing adoption in an industry that is so full of failed ones. Rust developers often trash Go but don't ask the question as to why Go was successful.

My understanding was:

• Short learning curve (even if that means "force things that are inherently complicated to seem simple at first glance)
• Giant company backing it (Google may not have poured as much into promoting it as Sun did with Java, but it matters)
• Easier to use as "like Ruby or Python for writing microservices, but faster-executing and with more of a type system"
• None of D's problems with a fractured ecosystem and initially proprietary compiler

TL;DR: Things that are inherently not possible when targeting the niche Rust targets because a lot of Rust's complications stem from the inherent complexity of solving certain problems without a tracing garbage collector, which would make it unsuitable as a C/C++ replacement, or the inherent complexity of guaranteeing memory safety, without which it would be just another also-ran in the C/C++ replacement space.

Still TL;DR: Asking why Rust didn't compete well with Go is like asking why C++ didn't compete well with Python. Their primary intended niches are too divergent. If anything, the surprising part is that so many people enjoy using Rust in a niche that you'd expect Go to be better suited for.

[ssokolow]

these does not sounds at all like what you say:

"Your comment gave me a good laugh. Not only is Go not a suitable replacement for C,"
"Go is not even in the same class as C, C++, or Rust for the mere fact that it..."

anyway, everyone has its own set of problems with programming languages.

My comment was a direct reply to what Thompson thought were the C problems.

It's certainly tactless, but "Go [is not] a suitable replacement for C" for the same reason neither Java nor Haskell is a suitable replacement for C: It's got a mandatory garbage collector. That's also why "Go is not even in the same class as..."

Why do I write Rust for tasks I could do in Go? Because it's easy to use things like PyO3 to expose bindings to my Rust creations in other languages so I can reuse that effort, while the official Rob Pike stance on Go is that "cgo is not Go".

[ssokolow]

I would rewrite everything in Pascal and release it under an MIT or BSD style license.

Even better, and I am 100% serious about this, write a proper compiler for Python and rewrite the whole thing in Python and release it under a truly free license, a simple 1 line that says "You can do whatever you want with this code".

Give this (English-language) analysis of the CC0 for suitability in Germany a read for why that doesn't work outside of legal systems descended from the British one:

https://rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf

(If you're not trying to put something into the public domain, it's mostly to do with laws meant to protect people from being exploited by publishers and movie studios where, unless you explicitly list what you're disclaiming, it doesn't get disclaimed, and you also need a secondary piece of legalese to restrict future you/rightsholders from being able to enforce any new "not allowed to be disclaimed before it's been granted" rights that may get written into law.)

[moltonel]

they could simply move from C compiler to C++ compiler and theorertically everything should compile, with some edge cases that need review.

Ha ha ha, "some edge cases" indeed. It would be madness to do it that way.

If C++ was to be accepted in Linux, it would need to be for new code only, and cleanly separated from the C code, just like is currently being done for Rust. The idea that transitioning to C++ is less costly than transitioning to Rust is pretty naive.

[darkonix]

Ha ha ha, "some edge cases" indeed. It would be madness to do it that way.

If C++ was to be accepted in Linux, it would need to be for new code only, and cleanly separated from the C code, just like is currently being done for Rust. The idea that transitioning to C++ is less costly than transitioning to Rust is pretty naive.

Thanks for the link. Very interesting analysis by someone that actually did the work. People usually underestimate the effort for this kind of thing.

[sdack]

As someone who was actually privvy to a lot of the back-and-forth chitchat between some heavy hitters in the Linux dev space starting around 1994/1995... C++ was despised. I'm not enough of a developer to understand why on a technical level (something something inheritance something camel case something), but C++ was thought of as an abomination with no place in any systems project, let alone the kernel. Obviously things change over time... a lot of that attitude may have been trickle down from Linus's fierce dislike. This is good popcorn fodder if nothing else. 🍿

C++ was and still often is seen this way. It is mostly people who do not understand the need for the kind of code control a large project has and thus find its features "overkill" or "abominable" or whatever. It is just what people say when they fail to need these features. It then has always been this way. Programmers rejected the first programming languages, because they argued they could do the same using machine code. With each level of sophistication will you find a group who will argue in the same way, that they can do the same using a lower-level language, and because they fail to see the need.

Since you have mentioned inheritance... I do remember a case where a superior of mine did not see the need for inheritance in C++! She preferred to copy&paste C++ classes to create new classes, instead of using a parent class to hold the duplicate code and to let the child classes inherit it. She argued that using copy&paste was quicker (in terms of getting the job done) than creating a parent class.

[c117152]

It was a mistake adding Rust, they should have waited for Zig imho.

Rust was added to develop complex APIs where C (and Zig... and C++...) were too human-error prone to use following Google's success in doing just that in Android. There's some other "side projects" exploring its fitness in network drivers and the likes... But regardless, it's all irrelevant to C++ or Zig since neither does enough to guarantee safety.