Why C++ Never Got Into The Linux Kernel

It is still very much in active development, there is a lot of driver work being done, but Rust has been in the Linux kernel for a couple of years now. As of December 2025, it was marked as no longer an experiment, and was successful. Now that this is the case, let's go back in time a little bit, and talk about another language that tried to get into the kernel. That language being C++. So you probably know, maybe you've heard about it at some point, that Torvalds is not a fan of the language. I can't speak for every single thing he said, but I do want to show you some very popular examples. Do keep in mind, this is discussion from a very, very long time ago, so it's entirely possible that things that are being said here don't align with the modern state of C++, and may not necessarily align with Torvalds' current opinions on the language. With that out of the way, let's take a look. Back on January 20th, 2004, in fact, in Linux, we did try C++ once already, back in 1992. So this is a 22-year-old post, based on, from that point, 12-year-older opinions. So, keep in mind, that some of the stuff being said here, may not necessarily be accurate anymore. The fact is, C++ compilers are not trustworthy. Now, this might sound crazy thinking about it today, but this actually was the common sentiment held at the time. Up until about the mid-2010s or so, a lot of people felt the exact same way as Torvalds here. They were even worse in 1992, but some fundamental facts haven't changed. The whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels. Technically, they can be avoided, and you don't need to use exceptions as a core part of your programming workflow, but they are a natural part of the language, and writing idiomatic C++ code, you're kind of expected to use them. Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. The idea of memory allocations being hidden isn't necessarily bad, because in the kernel, they actually do have some sort of abstractions that hide some of that memory allocation. But the difference here is they are specifically crafted for use in the kernel. The issue Torvalds has here is this sort of generic application of the model doesn't apply to something this low level. When we're talking about user space software, things like that, you can get away with doing things which aren't the best way to do things. But when you're interacting directly with the hardware, you want to know exactly how things are going, so if something goes wrong, you know how to fix it. You can write object-oriented code useful for file systems and other things in C without the crap that is C++. You have structs, you have pointers, you have function pointers, you basically have everything you need to make an object-oriented system. And if you want to write that, you can absolutely write that. It's not the natural way of writing C code, but it is something that is very possible within the language, and you'll find a lot of documentation and a lot of examples on how to do so. And if you want to do it, you can. But you don't need to have all of the extra stuff that a language that is built around that system is going to have. You can pick and choose the parts that make sense in your project and only have those. In general, I'd say that anybody who designs his kernel module for C++ is either looking for problems, a C++ bigot that can't see what he is writing is really just C anyway. You are literally just writing C code, but you're calling it C++, which is something you can do, or was given an assignment in a CS class to go and do so, feel free to make up D. But when we talk about Linus Torvalds and C++, a far more famous email is this one from September 5th, 2007. Both these emails can be found over on CatV if you want a direct link to both of them. This is a great website with a lot of fun posts on it. This is in response to someone saying, when I first look at Git source code, two things struck me as odd. One, pure C as opposed to C++. No idea why. Don't talk about portability. It's BS. And keep in mind, this is 2007 Torvalds. This is long before the Torvalds-ing, so he's got some choice words here.

You are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much, much easier to generate total and utter garbage with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C. Now, in retrospect, this is a really, really funny statement because this is exactly how a lot of people talk about Rust programmers. Like, word for word. Rust is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much, much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the Rust programmers out, that in itself would be a huge reason to use C. Could you not see someone saying exactly that? In all of these cases, though, there are great programmers in this language. There are great C++ programmers. There are great Rust C programmers. Frankly, there are great Scratch programmers. There are people who are incredibly talented, who dedicate all of their time to Scratch. I don't know why. You don't know why. I don't think they know why. But it is something that is done. A language is just a tool, and it does not define the quality of programmer. Whilst Torvald still isn't a big fan of the language, it is something he will use now. And in some of the projects outside of the kernel he's involved in, they do now have C++ code involved in them. In other words, the choice of C is the only same choice. I know Miles Bader jokingly said to piss you off, but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that would really prefer to piss off so that he doesn't come and screw up any project I'm involved with. Again, insert Rust into this statement, and I've seen this comment tons of times. C++ leads to really, really bad design choices. You invariably start using the nice library features of the language like STL, the standard template library, and Boost, and other total and other crap that may help you program, but cause some problems. Infinite amounts of pain when they don't work. And anybody who tells me that STL, and especially Boost, are stable and portable, is just so full of BS that it's not even funny. Again, this is from 18, 19 years ago. So, all five C++ programmers in the comments, don't get angry about this. I'm not the one who said it. Inefficient abstracted programming models where two years down the road, you noticed some abstraction wasn't very efficient, but now all your code depends on all that nice object model around it, and you can't fix it without rewriting your app. This is kind of a problem in most languages, to be entirely... This is honestly gonna be a problem in C as well. Not in the whole object idea, but if you write a bunch of abstractions, and then you rely on those abstractions, but you don't actually properly decouple things, you're gonna have the exact same mess. This model can be mostly avoided by not having these deeply inherited hierarchical models, which were really common in the 90s, and is the reason why you have Java, but nowadays are not really the way you write good object code. You can do it. Nothing's stopping you. But there's better practices now. In other words, the only way to do good, efficient, and system-level and portable C++ ends up being to limit yourself to all the things that are basically available in C. And limiting your project C means that people don't screw it up. So people that are writing in C++ don't go and start bringing in a bunch of C++ stuff, and even though it's available, limit themselves to just the C stuff. Which creates a whole mess of now trusting your developers not only to not write bugs, but not use certain parts of the library that is on their system. And also means you get a lot of programs that do actually understand low-level issues, and don't screw things up with any of the idiotic object model crap. Again, at this point, Torvalds was pretty much convinced that if you're a C++ developer, you have no idea how to write low-level code, and you're gonna do something wrong. So I'm sorry, but for something like Git, where efficiency was a primary objective, the advantages of C++ is just a huge mistake. This is actually a really funny statement to make at the time, because early on Git wasn't very efficient. It was actually really, really slow, and especially slow for what it was made for

a big mono-repo, that being the Linux kernel. Git wasn't the best choice available early on. Git had that early movers advantage being a distributed system when there weren't that many available, and also had the backing of the Linux kernel. So there was already this big project that showed that it could work, so that's a big part of why it was adopted. But at the time, it was really slow for mono-repos, and this is a big part of the reason why Facebook actually went with Mercurial, because early on, they actually weren't really that open to making some of the changes that would actually make it fast. It got a lot better over the years, and nowadays it legitimately is the best option, but that wasn't always the case. If you want to VCS a version control system that is written in C++, go play with Monotone, really. This is a project which has been dead for about, I want to say a bit over a decade now. They use a real database, they use nice object-oriented libraries, they use nice C++ abstractions, and quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. But I'm sure you'd like it more than Git. And never forget that one of Torvalds' oldest flame wars involving the kernel is with Tannenbaum, the creator of Minix, who was also a OS professor at the time. And the argument was about whether you build a monolithic or a microkernel. Torvalds was very much on the side of a monolithic kernel at the time. He was just like a university student who had just started working on Linux, and he was arguing, I think at the time, he might have been a tenured professor. So for a long time, Torvalds has had issues with people that don't actually go out and work in industry and build real things. And even though he had Minix, that was not the direction anything was going. Now, whilst Torvalds has absolutely no plans to pursue this route in the kernel, that doesn't mean that nobody is going to try to introduce it in various different ways, especially now that Rust is in the kernel, it's not going to happen. You're not going to have C, Rust, and C++. Now that you have Rust, that ship has sailed and is never coming back. Going back to 2018, April 1st. Convert the kernel to C++. Now, obviously, it's April 1st. It's a joke. It's April Fool's Day and nothing came about this. That's obviously what was going to happen, but there was actually some work done here. So, I don't know. Maybe there was something here and it was posted on April Fool's Day as like, oh, well, I'm actually doing this work, but if you don't like the work, oh, it's just a joke. Just, you know, you have plausible deniability if it goes wrong. Anyway, from there, there was sort of a revival of the thread come 2024. If you want to check out the entire thread of yourself, I'll leave it linked down below. There is quite a bit said here. Linus Torvalds never actually responded, so obviously it was never going to happen, but worth noting. But the main email I care about is the top one. Andrew Pinsky recently made me aware of this thread. I realized it was released on April 1st, 2018 and either was a joke or might have been taken as one. However, I think there is validity to it and I'm going to try to motivate my opinion here. Both C and C++ has had a lot of development since 1999 and C++ has, in fact, in my personal opinion, finally grown up to be a better C for the kind of embedded programming that an OS kernel epitomizes. I'm saying that as an author of a very large number of macro and inline assembly hacks in the kernel. C++ 14 is, in my opinion, the minimum version that has reasonable metaprogramming support, has most of it without type hell of earlier versions. C++ 11 had most of it. C++ 14 fills in some key missing pieces. However, C++ 20 is really the main game changer in my opinion. Although earlier versions could play a lot of... I've never heard this pronounced S-F-I-N-A S-F-N-I? S-F-N-A hacks? That is, substitution failure is not an error. I really hate people using acronyms for things that should not be acronymized. Yeah, we'll go with that one. They also gave absolutely useless bath as error messages. C++ adds concepts which make it possible to actually get reasonable errors. We do a lot of metaprogramming in the Linux kernel implemented with some often truly hideous macro hacks. These are also virtually impossible to debug. Consider the U-access to H-type hacks some of which I designed and wrote.

In C++ the various casts and case statements can be unwound into separate template instances and with some cleverness can also strictly enforce things like user space versus kernel space pointers as well as already verified versus unverified user space pointers not to mention easily handle the case of 32-bit user space types in a 64-bit kernel and make NDNS conversion enforceable. Now why not Rust? First of all Rust uses a different often in my opinion gratuitously so syntax and not only would all the kernel developers need to become intimately familiar to the level of getting the same kind of feel as we have for C but converting C code to Rust isn't something that can be done piecemeal whereas with some cleanups the existing C code can be compiled as C++. Nothing happened of this and very likely nothing is ever going to happen of this again now because of Rust being in the kernel there is just no reason to bring another language in most of what C++ was going to do over C is being done by Rust and some things are being done better so it just doesn't make any sense to bring another language in and deal with the complexity of that and then people complaining oh I don't like C++ is not going to happen but it is a fun bit of history to know that something actually was going on here and people have tried to do so let me know your thoughts do you think C++ should have been added to the kernel are you a supporter of Rust do you just like being angry I'd love to know so if you liked go like the video go subscribe as well and if you really like the video and you want to become one of these amazing people over here check out the Patreon, SubscribeStar, Liberpay, linked in the description down below that's gonna be it for me and C you later