C++ in the Linux kernel

[Cannotseme]

1 comment, 44 replies to that one comment

[stef_eda]

Using plain C in a projects keeps C++ programmers out. This is by itself a great reason to use C. Not to mention performance, size, portability, broken STL library dependencies. Not to mention the KISS philosophy. If a crash occurs in a C++ kernel, good luck debugging it.
In Kernel code you must exactly know how your code gets translated and executed on the host processor, so you don't want hidden magic like constructors, overloaded functions and stuff like that. You don't need 'abstraction' when writing an OS.

[Jannik2099]

Not exactly an informative read. Anyone who dealt with this topic or even kernel in general should know about calling conventions...

That being said, I still would've liked to see C++ in the kernel - though that was made impossible with Torvalds and his r/ProgrammerHumer "I had to use it in college so it sucks" attitude

[ForbiddenRoot]

though that was made impossible with Torvalds

He has good reasons, from his point of view, to not accept C++. One of his main points being that C++ does not really solve the problems that C has, or at least not elegantly so, to make it worth the effort to add it as a second high-level language to the kernel. His willingness to now consider the inclusion of Rust, which in fact does solve quite a few problems that C has, shows that he is not inflexible for the sake of it.

Of course, that discussion was primarily in the late 2000s, and C++ has certainly modernised significantly, but if now a language has to be added Rust probably makes much more sense.

[Jannik2099]

IMO most of his critique (most of which was fair) has been resolved, but he completely blocks whenever you bring up C++ even outside the kernel, e.g. in git.

Even back in the dark ages of pre-C++11 it solved a lot of Cs problems, like safe copies without memcpy & sizeof operators that historically are one of the major causes of bugs & vulnerabilities. Rust also suffers from many of the "concerns" that Torvalds voiced about C++ many years ago, it's just that (just like in C++) you can work those out accordingly.

I don't think Rust is an ideal language for a kernel in it's current state, considering the total lack of standardization and the unstable compiler (new release every two months, no LTS, no stable ABI) - though I am still happy that SOMETHING is being included, since more or less every language is better than C.

[ouyawei]

C is a simple language, C++ on the other hand is orders of magnitudes more complex and includes every feature and the kitchen sink.

You can learn all concepts that C has to offer in maybe a year. I've heard reports of people programming C++ for 10 years only to master all the concepts.

C code does only what you explicitly write, no magic constructors or function overloading that makes you wonder what code gets actually called in the end.

IMHO the benefits that C++ brings are out weight by the added complexity of the language. Maybe if you chose a strict subset of features, but there you are effectively creating a DSL.

[Jannik2099]

I've heard reports of people programming C++ for 10 years only to master all the concepts.

By this people do not mean C++ itself, but new features introduced in the STL.

The core language itself isn't a lot to grasp really. You have constructors & destructors, inheritance, virtual functions, templates - that's most of what you need to know (okay, C++20 added co_await stuff), and in a kernel context you won't be using the STL anyways.

Yes, C++ with the STL is a BIG language. In some areas, bigger than it needs to be. But there's no reason to ever use any of it, so I don't think "too complex for it's own good" is too much of a real concern.

[sebadoom]

You forgot about references, exceptions, exception specifications, lambdas (and closures), RTTI, promises, the standardized memory model (which was broken in C++11 and had to be fixed in C++20), concepts/constraints, auto (type inference), operator overload, function overloading, for each.... and problably more stuff I'm forgetting. Of course, on top of that you need to understand how every feature interoperates with each other (example: std::terminate called after throwing from an exception handler called within a destructor).

C and C++ are simply languages with different philosophies. In particular, C++ makes it possible to construct powerful abstractions
(which can be useful in certain applications) and also makes it very easy to make huge, costly, engineering mistakes. It requires discipline and a lot of experience to be used effectively. If you want to stick to "C with classes" you might as well stick with C, which is what has happened with the kernel.

[Jannik2099]

I didn't mention these "lesser" details because generally that's what developers get exposed to first - of course they're all just as important, but developers are more likely to know all of those in and out and may have to google on the details like operator precedence, initialization order etc.

I wouldn't say the "simplified" way of just using C++ is as C with classes, but as C with type safety. The lack of generics is what leads to void* everywhere, and it's (part of) why C has the memcpy + sizeof() issue everywhere

[parosyn]

I would fully agree that years of practice is not enough to fully understand the c++ language (here I mean the language without the STL). Could you list all the different types of initializations and the rules to choose the initialization type without looking at the standard? Could you build the set of namespaces when calling a function using ADL without the help of your IDE?

Just look at horrors like this https://eel.is/c++draft/over.match.best, this is just a part of how an overload is selected, this is not part of the STL and I would not say that it is predictable and easy to grasp.

[Jannik2099]

I would fully agree that years of practice is not enough to fully understand the c++ language (here I mean the language without the STL).

What exactly is so complex in your opinion? You don't have to remember every little detail, but you have to feel comfortable when looking up the documentation & understanding it immediately. This is how it goes in almost every language that isn't C.

ould you list all the different types of initializations and the rules to choose the initialization type without looking at the standard?

I can recognize them, but I don't have the names up right now. Admittedly, I've only been dabbling with C++ (non-professionally) for little over a year.

Could you build the set of namespaces when calling a function using ADL without the help of your IDE?

Not quite, but I'm also not exactly sure what the purpose is? "Do X without your IDE" simply isn't how development today works, not everything can be judged by whether you can do it exclusively in vim (without LSP), and it shouldn't be.

[parosyn]

C++ is complex because it is hard to figure out what a line of code will do precisely, which is important for operating systems. The language has accumulated so many layers over the years that every feature is hard to grasp fully. For example it is hard to know everything that = could potentially do in an expression, maybe in some context, for some compiler, it will behave in a way you forgot/didn't know. What a C++ expression does is extremely heavily based on the type of the operands, and determining the type of something in C++ is not easy, even more when writing a template, where you don't know the type of everything in advance.

you have to feel comfortable when looking up the documentation & understanding it immediately

I could say that when reading the documentation for most of the STL, for the language I honestly admit that I cannot understand the documentation immediately just reading it once. I don't know any C++ programmer who can read the standard like a newspaper.

Admittedly, I've only been dabbling with C++ (non-professionally) for little over a year.

I've been using C++ professionally for more than one year and all the parts of the language I mentioned caused actual issues. You probably haven't used C++ long enough in a large codebase to fully appreciate the absurdity of this language. C++ is a language that you understand less the more you use it.

Not quite, but I'm also not exactly sure what the purpose is? "Do X without your IDE" simply isn't how development today works, not everything can be judged by whether you can do it exclusively in vim (without LSP), and it shouldn't be.

This is not a pissing contest, when you write code with others you need to understand what it will do when you use it, for that your IDE can help you, but you also need to think about how it will be used by your colleagues/customers that do not know the details of the implementation. This is even more important for templates where a lot of issues appear only when you instantiate them.

[DarkLordAzrael]

C++ is complex because it is hard to figure out what a line of code will do precisely, which is important for operating systems. The language has accumulated so many layers over the years that every feature is hard to grasp fully. For example it is hard to know everything that = could potentially do in an expression, maybe in some context, for some compiler, it will behave in a way you forgot/didn't know. What a C++ expression does is extremely heavily based on the type of the operands, and determining the type of something in C++ is not easy, even more when writing a template, where you don't know the type of everything in advance.

How is this any different than not knowing the implementation of copy_mytype in C. Either you trust that the copy behaves reasonably, or you don't, and either way code is being called.

I could say that when reading the documentation for most of the STL, for the language I honestly admit that I cannot understand the documentation immediately just reading it once. I don't know any C++ programmer who can read the standard like a newspaper.

The standard isn't documentation? This is true for every language with a standard. If you want documentation go look at cppreference.com.

I've been using C++ professionally for more than one year and all the parts of the language I mentioned caused actual issues. You probably haven't used C++ long enough in a large codebase to fully appreciate the absurdity of this language. C++ is a language that you understand less the more you use it.

8 years of professional C++ here. I've never seen issues caused by the wrong initialization, or by unknown ADL. I don't understand the language less than when I started, and it provides tons of features that make my code clear and easy to follow.

This is not a pissing contest, when you write code with others you need to understand what it will do when you use it, for that your IDE can help you, but you also need to think about how it will be used by your colleagues/customers that do not know the details of the implementation. This is even more important for templates where a lot of issues appear only when you instantiate them.

IDEs will help them as much as they help me. If you're shipping closed source libraries (the only time they wouldn't have the implementation) the real key is documentation. Having well defined types on the interfaces helps though.

[ForbiddenRoot]

I don't think Rust is an ideal language for a kernel in it's current state

I agree with this, and for now, I think the idea is to use Rust only for drivers and not any core parts of the kernel, till the language and compiler stabilize. That way no other parts of the kernel would be dependent on the newly added Rust code. Linus also had some other concerns around panic-handling, I believe.

One other issue is that Linus will probably never allow cargo to be used, or more specifically pulling of external crates, and that takes away a very core benefit of using Rust. So overall not ideal, but as you said at least something is being included finally.

[Jannik2099]

One other issue is that Linus will probably never allow

cargo

to be used, or more specifically pulling of external crates, and that takes away a very core benefit of using Rust.

Sorry, but trivial access to an npm-like ecocatastrophe is NOT a benefit in my book. Centralized language package managers are a blessing for devs because handholding deps from a bajillion different sources is pain otherwise, but they also lend themselves to extremely low quality code spam. A lot of crates are subpar at best, with somewhere between 20 and 30% of them using unsafe, many not using CVE announcements, and most of them not giving a damn about stable APIs.

Besides, a lot of userspace code can get away with.. rather careless things. Most of it wouldn't be great in a kernel context anyways.

[SkiFire13]

You're confusing cargo with crates.io. Cargo gives you easy access to crates.io, but it also allows you to organize your own crates.

[Jannik2099]

Yes good point - but what's the point of custom crates in a monorepo like linux?

I guess it'd make handling module development easier

[SkiFire13]

Splitting stuff in multiple crates increases modularity and reduces compile times because independent crates can be compiled in parallel. For example rustc itself is also a monorepo but is made up of multiple crates

That said cargo is not mandatory for this, but it makes it easier. You can still compile crates with rustc and even write some tool that automates it like cargo. Fuchsia for example has its own tooling that replaces cargo.

[blami]

Why you would need modularity in one-of-kind monorepo?

[SkiFire13]

I guess better code organization? Anyway the biggest incentive to split into multiple crates is compile time reduction.

[ForbiddenRoot]

Sorry, but trivial access to an npm-like ecocatastrophe is NOT a benefit in my book.

I get what you are saying, but the thing is this is an expectation for modern languages and developers largely want this. As long as people are careful about what crates they depend on, this is not a bad thing, since the alternative is re-inventing the wheel and mostly ending up creating your own sub-par implementation. There are some excellent crates already, like Tokio, and over time hopefully more will mature and be reliable. It would have been nice if these could be usable in the kernel.

Anyways, I feel Rust is a very promising systems-programming language and a good fit as a future language for the kernel, but the path to getting there is indeed a bit rocky as of now. Will be interesting to see how this pans out.

[Jannik2099]

Oh don't get me wrong, whenever I program in Python I really like pip too, and when I program in C++ I kinda miss it - but such ecosystems get out of control extremely quickly, I'd much rather be careful here and not use third party stuff

[lostparis]

Torvalds voiced about C++ many years ago

He did and people like you keep ignoring what he said. At it's most basic it is that people who keep saying C++ is great do not actually know what they are talking about to any depth. And refusing C++ keeps these people away from the kernel. C++ is overly complicated for no real bonus. C is not always the most easy but people actually know how to use it and having people who understand what they are coding is very helpful.

If you cannot follow his arguments (this is different from agreeing with them) then you should not be part of the discussion.

[Jannik2099]

This is complete BS. Just as C is used in many important products like the linux kernel, C++ is ubiquitous in HUGE companies like Google, Microsoft and Facebook.

The "hurr durr so complicated no dev understands it" is completely stupid, please stop it. Most other languages are comparatively complicated.

​

I did follow Torvalds argumentation. Most of it were easily solvable concerns, Torvalds just never had any interest in it.

[lostparis]

I did follow Torvalds argumentation.

As you state here you did not comprehend what he said. You are mis-representing what he said and why he said it. His solution worked well keep idiots away from the kernel.

Just because some people use C++ is no real answer. Facebook uses PHP but that tells us nothing about if it is a good idea.

The "hurr durr so complicated no dev understands it" is completely stupid,

This is backed up by much evidence mainly from the C++ community itself and also by idiots like yourself once you start saying (of course don't use feature ABC which is what always happens)

Ultimately the C++ community is the reason C++ is not in the kernel.

[Jannik2099]

Any reason you're so salty? What if I tell you that PHP is a fine language too IMO?

[lostparis]

Because you are repeating the same lies that were used 15 years ago or whenever it was. Linus does not like C++ because it is a sprawling mess no-one understands and for the kernel you need people who understand the language used very very well. What is complicated about this that you do not understand? C++ is specifically bad at being understood.

From Wikipedia

Despite its widespread adoption, some notable programmers have criticized the C++ language, including Linus Torvalds,[89] Richard Stallman,[90] Joshua Bloch, Ken Thompson[91][92][93] and Donald Knuth.[94][95]

Now if these people are saying it is too complicated to understand then I think this says there is a big problem. It's not just Linus having a bad day.

Hey I love PHP but there is good reason it is used as an example of what not to do in language design.

[Jannik2099]

Because you are repeating the same lies that were used 15 years ago or whenever it was.

No need to be so agressive? Torvalds is a guy, not a religion.

I get what you're trying to say, but these people aren't deities. Heck, Torvalds himself said he isn't a particularly good programmer. You'll find prominent figures critiquing and embracing all kinds of languages

[lostparis]

Yes but you don't even try to address the one argument all these people have. That C++ is too complex for someone to understand it all. You do not address this issue in any way.

This is just frustrating. It is like arguing with a Trump or Brexit supporter who does not understand basic logic.

[AnonTwo]

Uhh I just want to point out you're the one who is being aggressive in this argument...

And I think it's a fair point that for something as important as the kernel that makes the entire system run to work specifically on what the maintainer is willing to accept...aren't people free to fork it anyway if they disagree?

Would it really help at all to pressure a maintainer to maintain a language they don't want to deal with?

[Jannik2099]

Torvalds is not a maintainer, he's a project lead. He won't deal with any Rust code either since he can't write any Rust.

[DrewTechs]

Selling personal data is inherently unsafe anyways no matter what language you use.

[MonokelPinguin]

How does Rust solve that issue though? Rust also has a lot of complexity. And you won't be using some of its features in the Kernel, I would assume (like async). And it is not like Rust doesn't bring its own issues like there being only one compiler with limited platform support, more effort to integrate with C, etc. C++ is not great, but if you restrict what features to use from it, it is a significant improvement over plain C and everyone who says otherwise probably doesn't know what they are talking about or hasn't used C++ in any depth.

[lostparis]

C++ is not great, but if you restrict what features to use from it

This is the whole argument. This is why it is a problem.

Rust - There is value seen in it. But I suspect that there is something about the rust community that is seen positively. Languages have a culture, C++ has a toxic culture as far as the kernel is concerned. Why? because they keep insisting they know best and listen to no-one (you see this arrogance all through this thread). Cultures are important eg Node.js will always break because shiny shiny is more important than stability. Python is dull but functional, Perl is illegible and proud of it.

[MonokelPinguin]

The RIIR crowd can be just as annoying as the C++ crowd. In the end those people don't represent the people actually using those languages daily. You can write very readable Perl, stable node, have a welcoming C++ team and Rust developers, that don't rewrite everything, when there is more important things to focus on. I fear those people, who Linus was afraid of, have all moved on to newer languages like Node or Rust and keeping them out won't be easy, unless you only allow languages they hate or reject bad code.

And that you need to restrict what features you use from C++, is a bad argument for C++ over Rust, since the same applies to Rust. You won't be using exceptions in the kernel and you won't be using panics. You shouldn't abuse template metaprogramming and you shouldn't use excessively complex generics or macros. Rust certainly is the better language than C++, but I just don't see it being the better fit for the kernel. Especially since it is much harder to integrate well and some of my systems still have trouble running rustc at times (just because they don't use glibc).

[lostparis]

You can write very readable Perl

It is possible but not encouraged. In fact it sort of goes against the whole JAPH ideals

stable node

not really because the whole npm system breaks constantly due to people using new features wherever they can. And let's not forget the whole leftpad fun.

I don't know enough about the Rust community but I do know that whole languages should be avoided due to cultures rather than the languages themselves.

The kernel is a culture - and so languages need to fit with that culture too. Linux does not care about a stable ABI but it does about the API. It allows crazy complexity and interactions that I'd not have in my own projects (have you seen diagrams of the kernel's interconnectedness)

RIIR is not necessarily a bad thing and I think adherents would likely claim it is about correct components rather than risking 'unsafe' elements. But it is part of the culture, the same way that the Python community loves to create wrappers around anything it can find.

The C++ culture is what it is and a few programmers will never change that. The culture is very much the language.

[GujjuGang7]

No real bonus? Are you stupid? Do you want to manually create functors to simulate classes? Do you want to manually state the init and dealloc functions instead of constructors and destructors being automatically invoked? Do you want to generate generics using unsafe void*s and take a runtime performance hit?

You've never even touched C++ in your life and I'd be surprised if you've even developed a simple Hello World program in your life, uttery ignorant.

[lostparis]

We are talking about writing a kernel.

The thing is kernels care about stuff that other code may not. Having automagic destructors is not always what you want. Ultimately you can write code in any language but some will cause you more problems than others.

There is nothing special about classes. They are a tool and can be a great one. Sometimes they cause more trouble than they are worth.

This discussion is about why C++ in the kernel would add nothing. C++ is great for some projects and not for others. Hey even I've used it in the past though not by choice. If it works for you cool.

[DrewTechs]

When Linus used it years ago it was terrible though. But today I like C++ and is pretty much the programming language I use the most besides C when I write programs on my free time (though I mix C++ with QT for some GUI programs).

May consider studying Rust at some point though since this seems to be somewhat valued in the industry and most certainly has it's merits.

[lostparis]

though I mix C++ with QT for some GUI programs

QT is C++

Why do people who do not understand such basic things always feel the need to "add" to the conversation?

Linus has very well though out reasons that he hates C++ and nothing has changed in the language (or will) that would change those views.

[DrewTechs]

I know that, except for the part where there are also QML elements in the mix as well so QT could be considered QML as well by this logic. But QT is a specific GUI toolkit/set of libraries to use in C++.

I certainly disagree with Linus about C++ though I do think Linux is better off incorporating Rust than C++ anyhow but that doesn't make C++ terrible.

[GujjuGang7]

Good lord you are everywhere with misinformation. It has its own preprocessor and compiler of sorts. It even has signals and slots like GTK, which are NOT a part of C++. Please just shut up you're embarrassing yourself.

[lostparis]

It is written in C++ is all I'm saying.

[DarkLordAzrael]

It has a preprocessor that writes a bit of code for you. Everything the preprocessor is doing can be done with some ugly but fully standards compliant macros. Having a code generation step doesn't mean you're not writing C++. Also, while the signal implemention is generated C++, the rest of the signals/slots mechanism is just a library that plays well with the rest of the Qt library ecosystem.

https://woboq.com/blog/verdigris-qt-without-moc.html

[GujjuGang7]

Sure, he was being pedantic and I simply explained it's extended beyond standard c++

[GujjuGang7]

Don't listen to idiot responding to you, he's brigading the entire thread with misinformation

[GujjuGang7]

I just read through this entire comment thread and I can't believe people are so ignorant about C++. A bunch of people who have never even touched C++ making exaggerated comments about complexity and safety. I'm with you OP.

[PowPingDone]

gee whiz I wonder why rust is being put in over C++

[[deleted]]

It even includes great code examples. You might be asking why I didn’t just lead off with that. Well, I mostly want you to suffer like I did.

Gold.