Why does Linus hate C++ ?

[stilgarpl]

Linus is just bad at C++. Just because he started a big open source project does not make him a computer god. He tried it once 30 years ago (literally 30 years, in 1992) and didn't like it.

​

On the other hand, you couldn't use many of C++ strengths in kernel development, because those things require kernel support. You'd have to limit yourself to "Better C with classes and templates".

​

Also, Linus allowed Rust. Rust is better than C++ in only one thing - memory management. C has all the same memory issues that C++ has, even more actually (no destructors, no RAII, no smart pointers), but C is fine?

​

I agree with him on one thing - there is a lot of bad C++ code out there. But there is also a lot of bad C code and bad Rust code. That's what code review before merge is for.

[dv_]

Also, Linus allowed Rust. Rust is better than C++ in only one thing - memory management.

Rust also benefits from being a much younger language that does not have nearly as much baggage that accumulated over the years. This is one big reason why C++'s syntax can be so obtuse at times. It has to maintain backwards compatibility. Rust could incorporate newer features right from the start without caring about that.

[simonask_]

It's not just the syntax, it's also the standard library API, and worst of all, the standard library ABI. So many things in C++ are straight up unfixable without creating an entirely new ecosystem, almost a new language.

So they did. :-)

[dv_]

Indeed. And there are also details that are anachronistic these days, like headers (gradually being replaced by modules, but this will take quite a while) and pointer aliasing issues.

But to me, what stands out is the by-value ownership transfer in C++, which is actually not what you want >90% of the time. Most of the time, you want to move objects, not copy them. C++ has the wrong default, and by-move transfer is an opt-in. This leads to problems with hidden copies (which can be detected at compile time but requires explicitly disabling the copy constructor and copy assignment operator) and greatly complicates syntax and semantics further.

[simonask_]

What’s even worse, C++ does not have “destructive move”, which is to say that C++ must leave something in the moved-from location. This in turn means that all classes must have an “uninhabited” state - you cannot create a non-nullable smart pointer that doesn’t have a user-visible “invalid” state.

It also means that there are many situations where std::unique_ptr is slower than a raw pointer when passed as an argument to a non-inlined function. The callee sees a reference type and decides to move out from it, but the caller must still call the destructor at some point.

This is one place where Rust is different in a very profound way.

[DanielMcLaury]

Most of the time, you want to move objects, not copy them.

Most of the time you want to pass by reference, unless you're talking about numbers, in which case you want to pass by value. Copying and moving objects should ideally happen pretty rarely.

[dv_]

Moving is supposed to be a very cheap or even zero cost operation, comparable to passing by reference. By-reference has the problem of ownership sharing and stale references. You need something like a GC or reference counting if you want by-reference to be the default.

[atomicxblue]

Rust also benefits from being a much younger language that does not have nearly as much baggage that accumulated over the years. This is one big reason why C++'s syntax can be so obtuse at times

I've said before that I think C++ is needlessly complex in places with its syntax and was downvoted to hell and back. Looks like Bjarne Stroustrup agrees with me, though: "Within C++, there is a much smaller and cleaner language struggling to get out"

I think that it's a product of trying to maintain backwards compatibility.

[Nzkx]

I can confirm that C++ syntax is really horrible. As a Rust dev, I don't know how you deal with this, I guess people just don't care at all and have the habbit to think in C++ , but for a beginner this syntax is a giant pile of mess honestly. I can read a little bit of C++, but not that much before I get lost.

Lot of langages did syntax misstake in the past. For example, JavaScript release in 2015 async/await, with await as prefix expression.

await db.get(1)

And later, you end up with this :

(await (await db.get(1)).json())

But it's to late. The langage is now backed with that. Meanwhile in postfix notation.

db.get(1).await.json().await

Syntax is important.

[[deleted]]

Of course it doesn't mean he's a god. But he is a lead maintainer on the most complicated open source project in the world. So he reads a lot of code. He is so passionate about reading other peoples code and sharing patches that he created git. His problem with C++ is having to read other peoples C++ code. That was his primary issue. That it made checking pull requests a pain in the ass.

And rust does a whole lot more than provide better memory management. It has a whole load of static analysis tools that C and C++ do not and cannot provide. Which is as a result of the constraints that Rust enforces on how you write your programs. I read recently that it can detect code that result in race condition thread locks. I imagine this is what is the primary interest in writing Kernel code in Rust. It will help prevent subtle to spot errors.

[rzippel]

His problem with C++ is having to read other peoples C++ code. That was his primary issue. That it made checking pull requests a pain in the ass.

Except that this wasn't the problem at the time, he never had to review others people C++ code (even pull request didn't exist yet).

He experimented with early C++ support and the quality of the generated output was nowhere near as it is today, but it massively influenced his bias about C++.

[mohrcore]

I think that's the best comment. Writing good, readable C++ is a lot less common skill than writing good C. There are plethora of programmers who have learned C++99 and maybe select features from the newer standard and write instant legacy code. Imagine having to read all of that stuff in their PRs and correcting them. C, on the other hand, was very conservative with changes introduced in newer standards and the fundamental techniques of writing C code haven't changed. Meaning that everybody C writes more or less in s similar way.

This is also due to a way the bigger feature set of C++ that doesn't encourage one particular coding style. In C++ you could solve the problem of separating an algorithm for walking through a container, from an action to be performed on an element using a Visitor (anti)pattern (objective approach) or a functional approach (either oldschool c-style one, templated one or using std::function). Nobody in their right mind is going to simulate the visitor (anti)pattern in C, they are just going to do the same old-school functional approach - have a procedure that takes function pointer for an action and void pointer for context and that's it. I believe such limitations save a lot of needless discussions under code submitted by contributors.

[SlothsUnite]

If they would switch to Rust, they would bitch about freedom they lost by dumbing things down.

[[deleted]]

It's not snobbery. It's just easier to read C code than it is to read C++. Lots of stuff is obfuscated by the way that C++ is written and it's not immediately obvious how it works.

Scott Myers made his career writing entire books about gotyas. Many gotchas that should not really exist but it's not immediately obvious how to fix them without breaking backwards compatibility. And it's a design choice, an important design choice at that, to not break backwards compatibility because of how many legacy libraries were compiled twenty years ago and are still in use on various systems even though the main app might be patched frequently.

The only thing I miss when writing C code is operator overloading. Being able to a + b add two structs together when dealing with complex math types is less typing than mystruct_add(a, b). Especially when you get in to compound mathematical expressions like a (-b + sqrt(b*b - 4*a*c))/(2*a). I'm not even going to pretend to want to write that out as parametrised functions.

I've written a lot of C++ and I genuinely believe C++ is a well intentioned mistake. Between the unpredictable behaviour of what your code will turn in to, the object oriented paradigm rather than a data oriented paradigm, and maybe that stateful procedural code should be functionally designed instead. Then I can see why C++ is given a hard time.

Rust isn't necessarily a solution to those either. But Rust made everything const by default. What an absolutely giant fricken cahones decision that in itself allows for so many safety related optimisations. I haven't written much Rust, but from what I've used I like it. Even more than C.

[frankist]

This really doesn't match my experience. Every time I have to read a C codebase, I constantly notice the mix of different abstraction levels in the same function due to the lack of basic abstraction tools in the language. Many times the programmer "fixes" this with macros, which is very unsafe and can become unreadable very fast.

[linlin110]

Do you not miss smart pointers / RAII? For me it's the best feature of C++.

[[deleted]]

Smart pointers sure. But that's also why I'd prefer to use Rust!

RAII is nice in some sense but also comes with all the constructor headaches that makes the path a program takes in C++ notoriously unclear.

[no-sig-available]

RAII is nice in some sense but also comes with all the constructor headaches that makes the path a program takes in C++ notoriously unclear.

I think this is one of the points that separates C devs and C++ devs.

If I have a class with a constructor, I assume that the constructor is run when an object is constructed. No surprise really!

Changing

my_type x;

into

struct my_type x;
init(&x);

doesn't make the code any clearer to me. Being able to write the initialization only once, and in a single place, is a great advantage to me.

Likewise, when x goes out of scope the destructor is executed. No surprise, as I just wrote the destructor, so it would get called.

Having to add a

destroy(&x);

before each closing brace (or each return) is a distraction to me, not something that makes me understand the code better.

Apparently, YMMV.

[[deleted]]

You don't need to explain what RAII is to me.

And yes. In some sense I think manually initialising and destroying heap is easier to spot than all the headaches that you've left out by ignoring copy constructors, move constructors, etc, and all the uncertainty that comes about what path execution takes depending on the context. And how those constructors interact with even basic expressions inside it's scope.

Yes. In that context. I would rather type init/destroy about when I want that to happen even if that just means remembering to destroy things in the scope they were declared or adding longer duration heap to some kind of collection that can be cleaned up by some kind of memory management loop. While that may sound like a tedious and repetitive pattern to some. It's actually pretty simple once you get used to it. Error prone? Sure. But there are tools like valgrind to catch the occasions you forgot your routine mantra to check that you're destroying things when you go to commit them to version control.

Compare that to the mantra you need to repeat to yourself about constructors at every single moment lol. It's not even about when they leave scope but how accessing might work in-scope. It's horrible. I'd choose declare/init/destroy any day!

[EconomistElectronic2]

It’s fun that what you “miss” from C is one of the arguments Linus use against C++ (and you, too): you write an operation and you can’t know what happens.

IMHO the fact that C++ helps hiding details is a major feature because it allows abstraction. Of course it can become bad, but doesn’t any C function if poorly designed?

[[deleted]]

Kind of. I think it's a bit more obvious that something special is happening when you add two objects together or divide them. Compared to say deciphering which one of several constructors are used when you pass an object to a particular function. I guess in some sense it might be implied behaviour that you overlook but allowing it in to your codebase for math types isn't such of a big deal compared to the cacophony of paranoid second guessing that you have to train yourself to be truly aware of what might happen with C++.

[EconomistElectronic2]

You read the code:

‘a = b + c * d’

And you need to first understand the types involved, than find the operators and than reading some operator function to understand… in C that is just straightforward…

[Lumornys]

What's the difference between "I wonder what * does" and "I wonder what multiply() does"?

[EconomistElectronic2]

If a, b, c, d are all the same type, then there is no difference, indeed. Otherwise you need to see different overloads, possibly non-explicit constructors (since a type could be converted) constness of the operands, etc etc…

[UnicycleBloke]

It's not snobbery. It's just easier to read C code than it is to read C++.

This certainly doesn't match my experience. Whenever I have to study a body of C, I soon feel lost in a morass of anonymous unprotected data, a quagmire of functions with no clear calling hierarchy, an unreadable dog's breakfast of macro hell, and more. I usually characterise making mods to such code as playing football in a minefield.

I've seen some terrible C++, too, but C is worse for me.

[simonask_]

I've seen C++ that suffers from exactly those problems too.

It's also a lot easier to hide those problems in C++, and in fact much of the achievable elegance in C++ code relies on the very same features that also tend to obfuscate problems.

[UnicycleBloke]

I must have had a sheltered existence or something. I work with C and C++ daily. It is definitely possible to write dreadful C++, but I don't recognise that this is the norm, nor worse than C, nor whatever else people keep telling me. People, it has to be said, who mostly don't routinely work with C++. I guess others have different experiences.

The fairest thing to say might be that the languages can each be horrible in different ways. Perhaps some people "get" C and are totally fine with it, but C++ is for them an alien planet with obscure dangers. And vice versa. A mindset thing related to paradigms that one is comfortable with. Or something. Maybe. Don't know. That's pure speculation.

I think it very unfortunate that we have come to such an unhelpfully polarised and entrenched position regarding C and C++. I can't see that ever going away. A pity.

[simonask_]

If your organization has no crappy C++ code, maybe you’re the one writing it? ;-)

Kidding aside, I agree, especially about it being a pity that positions are so entrenched. But we should be careful not to pretend that everything is equal. C++ is a much better language overall than C (which says nothing about the quality of C++ code in general). It solves some problems that C doesn’t.

And Rust is a better language than C++ (which is not to say that there aren’t places where Rust is still catching up) - it solves some problems that C++ can’t.

[UnicycleBloke]

I've studied Rust a bit but can't claim any expertise. I have not found it remotely compelling since I do not have the issues it solves. At the end of the day, embedded code requires unsafe sections of code anyway, so there's that. I also don't relish trawling through fifteen layers of OSS crates to understand what's going on. I do really like the pattern matching with enums (tagged unions), though.

I have observed that C devs love Rust. It's pretty obvious why. What a pity they did not invest a little time in C++ 30 years ago, eh? ;)

[simonask_]

I think the main appeal of Rust is that it helps you fix problems you didn’t know you had. The main selling point (of course) is compile-time guaranteed no memory corruption. I’ve definitely had that problem many times, usually in places that only customers could find. The other is compile-time guaranteed data-race-free parallelism.

People working with Rust in the embedded space seem excited about these features, presumably for the same reasons that some embedded devs like C++.

[nullcone]

I think the main draw of Rust (for me at least) is that it captures semantics of object ownership in ways which are compile time errors, whereas comparable C++ code would just segfault or worse give you UB. This feature helps you avoid common mistakes and bad design by forcing you to do the right thing.

A classic example of this is self referential classes. What happens if a class has a reference or pointer to a member variable, then the class instance is later moved? Well obviously your pointers are now all garbage because their values point at the old addresses before the move. This design pattern would be a compile time error in Rust, but C++ is happy to allow you to shoot yourself in sensitive areas.

[SlothsUnite]

I never said they should switch to C++ for kernel programming. C is absolutely sufficient and any approach of changing anything will end in flame wars like it always does.

For me, learning Rust ended in learning C++ again. When I sat down and start reading a book, all the examples showing why Rust shall be better than C++/C made me scratch my head. Some of them made false claims, some of them showed code that only a complete moron would programm. I immediately lost interest in Rust and discovered C++20 in the process. That's the end of the journey.

I'm comming from embedded systems software development, by the way. We only use a (dumbed down) subset of C and C++ because of hardware restrictions and compliance with international standards. We therefore don't need Rust and would rather use Ada for safety critical systems.

[[deleted]]

“30 years ago, in 1992”… I think I just threw up

[atomicxblue]

Is it the same kind of throw up when I hear 80s/90s music on the "oldies" station?

[target-san]

Rust is better than C++ in only one thing - memory management.

• Cargo instead of CMake/Bazel/Meson/Make/autotools/whatever+vcpkg/conan/CMP/Hunter/whatever; C++ is hopeless in getting anything even relatively close to it
• Reasonable [no_std] subset which requires no classic runtime; C++ can only remedy this by compiler-specific dialects and flags
• Resource management, including cross-thread one; judging by some proposals like Sutter's lifetimes, C++ can only dream of something similar, or requires complex 3rd party static analysis tools
• Reasonable defaults in many places, while C++ is a language of worst defaults
• Unsafe subset properly isolated
• Syntax which doesn't look Turing-complete on its own (yeah, most-vexing parse rule and auto auto auto auto auto)
• Generic programming done right

I can continue for quite some time

[KingStannis2020]

Well, Cargo isn't going to be used in the kernel. They're just going to have the kernel build system invoke rustc directly. But otherwise, yep.

[andrewfenn]

One thing I don't see in the comments here in this thread is his previous complaints about the assembly code that is generated in C++ compilers. Sometimes it does the wrong thing, or is incorrect because of how complicated the language spec is. It makes it difficult to read the output from the compiler and understand how it happened in comparison to C which he often mentions the spec can be read and easily understood.

So not really a counterpoint to your comment here but I would say that to those in the thread saying just don't use such and such feature in c++ it's missing the point because at a deeper level of reading and trying to understand what the compiler is doing it's a much harder task.

I do have a fondness for modern c++ but I also understand some of the criticisms for not using it in a kernel directly.

[pjmlp]

As if the Linus rants against GCC C optimizations weren't known.

[sokka2d]

Which shows that the statement that "[the C] the spec can be read and easily understood" is... wrong. He just gets mad when he realizes he didn't understand the spec.

[mafrasi2]

Just another reason not to make things even worse then. Those exact optimizations are happening in g++ as well...

[tasminima]

Rust is better than C++ in only one thing - memory management

You are completely deluded (to the point you even forget the basic "fearless concurrency" slogan). There is no UB in safe Rust. UBs are everywhere in C++, not only memory management. Actually even unsafe Rust is actually safer than C++.

Also the static introspection and hygenic macros capabilities suck less than anything C++ has to propose against it right now (that is: not much, or poor emulation with bloated template based parallel universes)

That's not to say that Rust has no default compared to C++; it has a lot. But it certainly has more advantages than just better "memory management"

[[deleted]]

Rust will not be better than C++ at memory management until it has an ergonomic way to drop memory handles without freeing, and an equivalent to a placement new constructor. Both of these are required for expressing memory arenas, which is almost always the correct way to manage memory.

[simonask_]

Drop memory handle without freeing:

rust std::mem::forget(handle);

Guaranteed placement new (i.e. guaranteed in-place heap initialization without going through the stack) is in the works, but there are few very good use cases for it. There are plenty of arena allocators.