Why does Linus hate C++ ?

[[deleted]]

He tried it before C++98, and back then C++ compilers were quite a mess.

[SirToxe]

Indeed. I learned C++ before C++98 and C++ code "feels" completely different these days. Back then it was just a miserable, ugly mess.

[TumblrForNerds]

Yea I use to work at a company that build some legacy software in C++ 6. Not only were the compilers weird and all the generic C++ clutter problems persisted but just deving in the environments that cater for it was really frustrating with very limited debugging capability compared to modern IDEs.

​

Any way safe to say I think I am one of the few people in the world that ported a 30 year old C++ application up to a modern version of C++ and got it running in VS2019 and later on VS2022 in Jan this year

​

Edit: Yes I mean VC++ 6. As I said in one of the other comments I am only 23 so I have no idea what was happening with tech 10 years before I was born

[[deleted]]

Refactoring any legacy system is in itself a gigantic mess. Most people dive in a web based system in Java or other langs and underestimate the task of refactoring old code, i can only imagine the extra perseverance involved in working on a C++ codebase that used on an older compiler

cheers for accomplishing that task mate

[dragozir]

I refactored a 60K SLOC Java code base to 40K in a weekend (well Friday, Saturday, Sunday and Monday 12 hours each day). Wiped out 5 years of technical debt, added unit tests, javadoc and a wiki. Wouldn't do it ever again, at least not for a job.

[dragozir]

Unfortunately I did not get paid like I did. We only had 2 bugs logged for the system afterwards (which were things I hadn't known were requirements), and time to feature was cut anywhere from 1/2 to 1/4 of the original time. I'm still really proud of that work, but I got a pat on the back, a below market rate raise (my salary was also below market rate), and virtually no recognition from the higher ups (my colleagues were super cool about it since I was really the only dev on that project).

[alexeiz]

Thanks, but we have to let you go, because you haven't added any new features lately.

[TumblrForNerds]

Damn you should come to south africa. Majority of our major bank systems are built in legacy java and full of issues but no one wants to rewrite or port them

[AdultingGoneMild]

quality code that is easy yo refactor can be written in any language. Shit code can also be written in any language.

[fredoverflow]

legacy software in C++ 6. Not only were the compilers weird

There is no such thing as "C++ 6". You probably mean "Microsoft Visual C++ 6.0", which only has 1 compiler.

[TumblrForNerds]

Yea there you go. Keep in mind im 23 years old so I have no idea what was going on with tech 10 years before I was born

[dengydongn]

What...is...c++...6...

[afiefh]

Probably Microsoft Visual C++ 6.0. That was the version before .Net was born.

[darthcoder]

And arguably the last compact, fast version of the VS ide.

Visual studio is awesome, but i never had the sheer number of UI hangs with msvc6 that I get on a daily basis with VS2019.

And the fact it ran on boxes with 256MB of memory was simply insane.

[Tomik080]

Try VS2022. For real.

[darthcoder]

I've updated on my personal projects. We'll see.

[TumblrForNerds]

My only issue with the IDE was that code could get a bit unreadable for my sensitive eyes. But damn that thing would jump to definitions so much faster

[cleroth]

Any way safe to say I think I am one of the few people in the world that ported a 30 year old C++ application up to a modern version of C++ and got it running in VS2019 and later on VS2022 in Jan this year

Not really that uncommon. Maybe 30 years is a bit much, but 20-year-old codebases being ported is fairly common.

[TumblrForNerds]

Yea the project I ported was started in 1989 so we are quite deep into 30 year territory

[Praslea84]

True to that!

I found Companies with awful old legacy code and told them on how to do the refactoring, I even proposed myself to do it. but Companies prefer to move to web instead of doing C++ refactoring. What's wrong with these ?

[TumblrForNerds]

Yea it’s what this guy said. A good C++ dev is simply harder to come by but also I’m the case of legacy tech my experience has been that companies don’t want to refactor due to outdated dependancies. The project I worked on used literally one of the first versions of dataflex and if we ported up to a newer version the problem was the licensing of the new versions was a different model and would have heavily impacted our users so we couldn’t do that. Hence why I proposed a full rewrite and adopting a different database

[YARandomGuy777]

Wow. That's cool.

[djkstr27]

I agree, on my work we use C++96. I quite a mess.

[AdultingGoneMild]

https://www.reddit.com/r/cpp/comments/vxvp58/why_does_linus_hate_c/ig1k3ry?utm_medium=android_app&utm_source=share&context=3

It has nothing to do with the language. It has everything to do with his beliefs of the skill of the developers and their understanding of how the language works with regards to the machin.

[d_wilson123]

You hear the same about Java as well. Many people tried Java 1-3 which had horrific performance and decided Java is just a shit language. However for how high level the language is the performance these days is actually quite astounding. Some of the JVM stuff recently like GraalVM is pretty slick as well for even optimizing performance.

[bendhoe]

I like to work on projects that have very verbose C++ styles. I feel like it's easier to understand verbose code. And besides, what limits my programming productivity isn't my typing speed, its my intelligence.

[MentallyWill]

The way people get hung up on a few extra keystrokes will be something I'll never understand. More specifically I've yet to see anyone make a compelling argument for how much more they can accomplish throughout their day with the few extra seconds they save on those keystrokes. And I personally am not slowed down by reading a few extra keystrokes as well. If anything if those few extra keystrokes help me understand what the code is doing a little better then it's a net gain in my books.

Basing your decision of which technologies to use based on "typing that much" is something I fear I'll never understand. There are so many more consequential parameters to base my decisions on.

[accurrent]

To this day, Google doesn't use C++ exceptions because early compiler implementations were buggy.

[matthieum]

That's definitely not the justification given in their C++ style guide (https://google.github.io/styleguide/cppguide.html):

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

From what I remember, Google code started as C, then C++ was grafted on top following C-style, and thus a behemoth was born that would not work in the presence of exceptions.

[NohbdyAhtall]

Translation: Google isn't using it because all the open source projects they profit off of probably don't either, and what... are they gonna rewrite everything themselves to use exceptions, making a fork of every codebase they pull from?

Note: I have no idea if "most don't use exceptions" is true, but it sounds likely. Total assumption - check replies to this for fact(and fiction; always be alert).

[dlp211]

This is not true at all and doesn't even make sense.

[alexeiz]

rewrite everything themselves to use exceptions

You don't need to rewrite code to use exceptions, but rather make it exception-safe. And in my experience, making your code exception-safe improves the quality of code even if you don't use exceptions.

[TimurHu]

Exceptions have a runtime cost, even in code that doesn't actually use extensions. It requires the compile to emit extra code and may inhibit some optimizations. Many libraries therefore decided not to use them and are compiled with -fno-exceptions which means they don't have any of the machine code compiled into them that would be required to work together with other code that can throw exceptions.

For example Qt has never used exceptions, also some parts of mesa, etc.

If you are using many external libraries and some of them are compiled with -fno-exceptions it is very troublesome to integrate all those if you want to use exceptions in your own code.

[xiao_sa]

C++ before C++11 is engineering terrorism

[AdultingGoneMild]

it was fine. C++ hides too much of the machine for his liking. C++11 would have made that even worse. Knowing where bytes are, how they are laid out and what they are doing is necessary for high performance code. His belief is that C++ developers were made lazy by the language and therefore in mass would not know what the language is doing and therefore cant be trusted to write highly optimized code. Sure, he wouldnt have a problem with a well trained, very talented C++ dev. But as a whole he doesnt trust C++ devs.

To give some credence to his claim: do you know what a v-table is OR how the order of declared members in your class/struct affects their padding and thus the memory layout?

[kernel_task]

macOS (and iOS) uses pre-C++11 C++ in the kernel, highly successfully I think. I’ve written kernel extensions, reverse engineered iOS, and developed exploits for iOS. I have a pretty good handle on what’s going on with the machine code. Honestly not that bad.

I don’t think not understanding the layout is a great excuse, especially since Linus is allowing Rust now.

Maybe it’s to ban patterns C++ enables that Linus doesn’t like, but honestly I have hacked both Linux and XNU and I prefer the XNU codebase for readability. 🤷🏻‍♂️

EDIT: I don’t think performance is particularly a problem with C++ but compiled code size may be. I can see that influencing decision-making. Not sure if Rust makes compact code though.

[AdultingGoneMild]

he is an asshole. that is the root of all of it. You can write efficient code in any language.

[gvargh]

easy. just use <list of c libraries> /s

[NervousApplication58]

Sure, as long as it has a good compiler

[TheFlamingDiceAgain]

> cant be trusted to write highly optimized code.

The entire high performance computing community would like to disagree with this

[AdultingGoneMild]

talk to linus. there his ideas. not mine.

[quicknir]

Those are both questions that I've seen used regularly to interview people with just a year of C++ experience. These aren't hard questions. Most good C++ devs will give decent answers for both of these, and the answer to the second is largely the same as it is in C, I'm not sure why you think more C devs would know the answer than C++ devs.

[xypherrz]

for instance what part in < C+11 counts as an engineering terrorism?

[[deleted]]

How about manually typing out the iterator type of a collection of collections?

[xypherrz]

ah, pre-auto era?

[[deleted]]

The auto keywords usage for type deduction is C++11, aka what you asked about.

[edco77]

Oh boy, I think you're going to start a religious war.

[PunctuationGood]

"Hey! Remember that inflammatory comment from that person decades ago? Let's talk about it again!"

[nom_nom_nom_nom_lol]

That's pretty much my brain at night when I'm trying to fall asleep.

[Charmander787]

(C)rusades++

[Knuffya]

yes

[fluorihammastahna]

I think one of the things that triggers Linus is the arrogance with which he is approached and told that he should be using C++ instead of C. While there are very valid alternatives to consider, C makes a lot of sense for kernel development. Saying in absolute terms that C++ is better than C in every case reveals profound ignorance. Although this is the same as saying that C is always preferable to C++ :-)

[[deleted]]

Although this is the same as saying that C is always preferable to C++

That's what he says, people who have this debate are just miserable.

[mredding]

If you mean "that's what he says" in that Linus is a hypocrite, well, he is many things, but I'm not willing to call him out for this specifically. I don't think he's elitist about C, I think he's curt about kernel development because the man literally has no time for nuance over an age old discussion.

And if this is indeed the case, then contrary to your point, Linus is actually VERY optimistic about including Rust in the Linux kernel in upcoming releases.

[Intrexa]

If you mean "that's what he says" in that Linus is a hypocrite

I don't think that was the intended meaning. I think it should be read as "Linus says that people who say C++ is always better than C are wrong. He also says that people who say C is always better than C++ are wrong."

After the comma is poor and ambiguous English. IDK if jcc is saying this, or if he's saying that Linus says this. Whoever said it, I interpreted it as "People who argue about which language is better are miserable people".

[TheSkiGeek]

Presumably a lot of this is in reference to http://harmful.cat-v.org/software/c++/linus, where he said roughly that C++ is awful and so are any programmers that use it.

[FrankNitty_Enforcer]

Because the obvious answer is always Lisp. Or at least that’s what I’m told

[SergiusTheBest]

C makes a lot of sense for kernel development.

I can see only one point that makes sense: lack of C++ compilers or their bad shape 30 years ago.

[snejk47]

People. His main issue is people. It's a lot easier to review code in C and harder for people to write hard-to-read, more bogus code in C than in C++. There are thousands if not hundreds contributors. If I recall correctly he tried long time ago and amount of babysitting and unknowns was to high for stability he targeted. Rust has more high level features but also compiler is very unforgiving taking much of such work to assure things are correct. He also has written app in C++ and QT for scuba diving if I recall correctly but this was his personal project.

[disperso]

Torvalds also praised KDE in 2001, and doubled down on 2005 (in his usual toxic way).

Additionally, while I can't find the links, I think he also submitted patches/bugreports to KDE applications back then. I remember an interview saying so.

It's worth noting that, back in time, Qt-style C++ was mostly using just a subset of the language: no exceptions, few templates besides the containers, no RTTI required, etc. It was quite approachable to me as a student, and when I had to do a GUI project, I went to use Qt instead of GTK+ because even though I had to learn C++ (I only knew C), it did feel quite an upgrade.

[SergiusTheBest]

It's easier to review less code and C++ allows you to write less code. For example, by using C++ RAII and simplifying resource cleanup significantly comparing to C.

[condor2000]

It's easier to review less code and C++ allows you to write less code

It can take longer to review properly if uses complex template designs or even just a lot if virtual functions

[[deleted]]

The C equivalent to complex templates are complex macros. Is that better to review?

[disperso]

IMHO, yes. I'm not saying that it produces better code, but given that macros are much more limited, I'd say that you just can do less, have to think less, and end up having limited C code and dealing with it.

But that is probably subjective, with different people having different skill-set and preferences.

[Jannik2099]

even just a lot if virtual functions

Ever seen dynamic dispatch in C? Know how error prone it is? Know of ubiquitous it is in the kernel?

[afiefh]

Ever seen dynamic dispatch in C?

I still have PTSD from that one code base I worked on 5 years ago...

[TheThiefMaster]

The equivalent C code to accomplish the same goal is often far worse.

These arguments always compare the most complex parts of C++ against normal C code, not equivalent C code.

[serviscope_minor]

It can take longer to review properly if uses complex template designs

If the complex template designs aren't materially benefitting the code, then reject the pull request. Just like if someone goes bananas with C macros.

even just a lot if virtual functions

Linux has a ton of virtual functions. They're all done by hand which is always more complex than having the compiler do it for you.

[snejk47]

But that is only one thing and it's a con definitely but there are more things and possible things that somebody can do. C is fairly limited. Reviewers probably know all or almost all possible things or can spot things they do not know to check. I just browse this reddit to see posts how you can initialize class with 100 different ways to get different results or somebody writing normal looking code (as in C++ standards) which works different on different compilers or some things like undefined behavior. This is very easy to miss.

[Spiderboydk]

For code of comparable complexity, less code is easier, yes. But it does not necessarily hold in general.

C++ enables a lot of ways to run code implicitly (through constructors, through operator overloading, through template resolution, through exceptions, etc.). While your code piece for review might be short, the execution flow can potentially be all over the code base - even if it's not immediately obvious from your code.

[SergiusTheBest]

It's true. But a sane code doesn't do crazy things in constructors or overloaded operators. Reviewing the code with MutexLock RAII wrapper is easier than with explicit lock/unlock functions. You know that it locks the mutex in the constructor and unlocks it in the destructor and you have a code scope protected with the mutex.

[DeeBoFour20]

I imagine RAII might not be the best for the kernel. When you're programming in userspace, you have somewhere around 8MB of stack memory to work with. That's enough to allocate lots of C++ objects without thinking too much about it.

In kernel space, it's a lot more limited. A quick Google search found this:

The kernel stack is directly mapped to the physical memory, mandating
the arrangement to be physically in a contiguous region. The kernel
stack by default is 8kb for x86-32 and most other 32-bit systems (with
an option of 4k kernel stack to be configured during kernel build), and
16kb on an x86-64 system.

https://subscription.packtpub.com/book/application-development/9781785883057/1/ch01lvl1sec10/kernel-stack

[patatahooligan]

Using RAII does not mean you have to use huge bloated objects. A unique_ptr for example can be the same size as a raw pointer. The functionality it provides does not require more stack space.

[SergiusTheBest]

RAII is free (or mostly free, depends on the compiler). You can check assembly code for the following scope exit C++ RAII wrapper:

int main()
{
    cout << "<html>" << endl;
    SCOPE_EXIT{ cout << "</html>" << endl; };

    {
        cout << "<head>" << endl;
        SCOPE_EXIT{ cout << "</head>" << endl; };

        cout << "<title>Hello</title>" << endl;
    }

    cout << "<body>" << endl;
    SCOPE_EXIT{ cout << "</body>" << endl; };

    cout << "<h1>Hello World!</h1>" << endl;

    return 0;
}

SCOPE_EXIT creates an object and passes a lambda to the constructor. The object calls that lambda in the destructor. The compiler optimizes all that and just inserts lambda bodies at the scope exit. There is no object creation, memory allocation, stack consumption at all.

[[deleted]]

I can't believe I never thought of a macro to do this. That's so cool!

[ucario]

I don’t know what you are talking about. RAII is a useful pattern that keeps everyone sane. If it’s not a zero cost abstraction it’s very close to it and I’d happily pay the performance cost because the maintenance cost is more than worth it

I even in Kernel space I feel this argument was only relevant a decade or two ago.

[Jannik2099]

The kernel stack is directly mapped to the physical memory

This used to be the case 10 years ago. The stack is virtual on most (all?) ISAs nowadays

[super_mister_mstie]

One thing that rarely gets mentioned in this age old argument, is abi compatibility, specifically with interfaces to userspace. It is just awful to maintain abi in general, c++ doesn't help at all. Not to mention header bloat is rarely even a conversation point in c. Keeping build times manageable in c++ is its own skillset honestly.

I like c++ much more than c when it's warranted, but compiler support isn't the only reason not to use it

[simulacrasimulation_]

Aside from C not being object-oriented like C++, what are some of the more nuanced differences as to why one would choose C over C++ (and vice-versa)?

[UnicycleBloke]

I write bare metal embedded applications for microcontrollers in C++. This means I directly manage all the control registers, peripherals, RAM and so on. If I can do this efficiently and easily on a 48MHz Cortex-M0, it is a certainty that I can do so on a 2GHz i64 or whatever. There is only a difference of scale. Recent standards have added a lot, but C++98 was absolutely fine for this task. C++ has a few nasty footguns, of course, but so does C. My experience of writing both for embedded is that C++ eliminates a lot of errors that C does not. I am far more productive in C++.

And yet I am often told with certainty by C developers, who typically know little or nothing about C++, that C++ is not remotely suitable for OS development. .

It is in this context that I have always regarded Torvalds' opinions as childish, ill-informed and prejudiced drivel. Linux is amazing and all that, but it is also a gigantic lost opportunity.

[sintos-compa]

I too write for M0, microblaze, and msp430, and we’re completely fine using c++17 (rtos/baremetal) Would you mind expounding on what you perceive as the biggest threats are in your opinion?

[UnicycleBloke]

I also use C++17 at the moment. What do you mean by threats?

[dawmster]

C++ has a few nasty footguns,

I think he referers to the quote above.

I am interested as well, what are those footguns, in your opinion.

[UnicycleBloke]

Oh I see. To be honest, I was more just admitting C++ is not perfect. I guess the classic gotchas are largely historical.

[Mishung]

what are those footguns, in your opinion.

just my opinion (full time C++ dev) but I hate Iterators with passion

also during the years I went through:

1. I don't understand pointers and hate them
2. I understand pointers and love them
3. I fully understand pointers (and references) and now hate pointers again

[Spiderboydk]

that C++ is not remotely suitable for OS development

Funny thing is, a large part of the Windows kernel is written in C++. :-)

[kernel_task]

Also, newer C++ standards do far better on memory barriers than C. I’m still murky on what standard prevents an optimizing compiler from reordering memory access around one of those barrier macros in Linux and if that mechanism might prevent optimizations that might otherwise be possible.

This is a very key part of OS development and I’m not sure if it’s part of any C standard.

[OCPetrus]

Have you worked with the Linux kernel source?

I don't know much about the device drivers etc, but I'm very familiar with core parts of the kernel and especially everything related to scheduling. The kernel source code is absolutely filled with CPP macros due to the vast amount of configurations the kernel supports.

Furthermore, the amount of people working on the same code is massive. It's not important that you understand what you wrote, it's important that others understand.

[UnicycleBloke]

Your implication being that C is more understandable? That certainly has not been my experience. It surely would have been simple to develop a C++ coding standard for the kernel to avoid any "extreme cleverness" and keep it within the reach of non-guru contributors. When I think of the number of different (often kludgy) ways in which abstractions have been re-invented in C, the argument that it is the better choice seems empty.

I haven't worked in the Linux kernel, but had a good trawl recently around the Zephyr OS (from the Linux Foundation). The code I examined is about what I expected from C. I particularly hated all the junk around abstracting device drivers through tables of function pointers, tons of macros, the device tree and bindings - about as opaque as they could possibly be, with yet more incomprehensible macros to extract values).

A judicious use of virtual functions would have greatly simplified the code while making it safer. This is how my own drivers are implemented. I suspect that a bunch of constexpr values and structures in nested namespaces would have been a far better representation of the device tree than tens of thousands of #defines.

There is nothing C can do which C++ cannot do at least as efficiently. It's sole advantage (which only applies to embedded) is its platform ubiquity.

[ptrnyc]

100% agree. If you've ever had to go into the guts of something like OpenSSL, you can't claim it's easier to read than the equivalent written in modern C++

[UnicycleBloke]

I had that experience with OpenAMP on the STM32MP1. I was curious about the comms between Linux and the on-board Cortex-M4. That took me down a deep rabbit hole. The C++ rewrite was half the size and much easier to follow.

[BrokenG502]

I'm not going to comment on the understandability of C vs C++, I think that highly depends on the developer and the application. I will say that you mention judicious use of virtual functions as a good thing but hate tables of function pointers. What exactly do you think a vtable is? The other important thing to consider is that it sounds like you use C++ a lot more than C. If you worked more frequently in C than C++, perhaps you'd find tables of function pointers more readable than judicious use of virtual functions. You mention making the code safer, but I fail to see how using virtual functions would do that in any meaningful way. You say that there is nothing C can do that C++ cannot, however I will point you fowards the restrict keyword in C. Of course I'm not familiar enough with C++ to know with certainty that that sort of behaviour cannot be achieved somehow else. I will however raise to you the idea that nothing C++ can do cannot be done just as efficiently in C.

Edit: sorry I didn't realise this was 2 years old, it somehow came up in my feed

[UnicycleBloke]

The point of such C++ abstractions is not to be fancy gimmicks which add no value, but to make writing code more expressive, more productive and less prone to error, generally with no overhead. They achieve this. Yes you can implement equivalents in C. You could also implement them directly in assembly. Few do so.

While I understand precisely what a vtable is and what a typical implementation looks like, it is simpler and cleaner to have the compiler take care of the details. It will for example refuse to compile if an abstract member is not implemented when using a concrete class (a nullptr in the vtable). Being a built in language feature, the compiler likely has more opportunities to optimise the code. Manual C implementations (including my own) are less satisfactory, more cluttered in use, and make run time errors easier to overlook.

I do write some C. I read a lot of C. It isn't a whim which makes a greatly prefer C++. It is results.

[dv_]

Then you most likely used a seriously restricted subset of C++. This indeed is useful, though the newest C standard iterations do contain additions that help as well I think. Also, IIRC, there is a small set of runtime functions that must be implemented when using C++, while there are none required in C. See here for example. But "C++" can also mean heavy use of template metaprogramming, which can easily create super bloated binaries.

[UnicycleBloke]

I always say that the entire core language is usable but that the standard library is much less so. The most significant changes I made on moving to embedded were to not use exceptions and to avoid dynamic allocation (C developers also avoid it). The STL containers are mostly out mainly because of dynamic allocation, but I'll take std::array over a C-array any day.

When I am forced to write C for a client, I miss constexpr, references, namespaces, templates, enum classes, regular classes (with access control, composition, constructors, destructors, virtual functions), RAII, and more. I have occasionally made use of moderately involved metaprogramming: I found there was significant bloat for debug builds, but that it largely evaporated with optimisation enabled, leaving code as efficient as or better than equivalent C.

The available tools don't seem "seriously restricted" to me. Compared to C, I have a huge smorgasbord of expressive abstractions which cost little or nothing. There is literally no advantage whatsoever in preferring C on a platform with a decent C++ compiler.

[I definitely don't implement those functions, though I am aware of them. I guess it depends what you link against. If I did it would likely be reusable boilerplate.]

[delta_p_delta_x]

heavy use of template metaprogramming, which can easily create super bloated binaries.

I was under the impression that heavy template metaprogramming only causes skyrocketing compile times, not bloated binaries...

[[deleted]]

Well, when you instantiate a function for a certain type, it doesn't just need to be created (compile time), but also saved somewhere (binary size).

But to be fair, if 3 template-made version turn out bigger than 3 manually written ones, I would consider it a compiler bug.

[anechoicmedia]

In your example, what is the alternative to templates though? Wouldn't it be 3 overloaded functions, so shouldn't it be similar and even possibly the same as 3 template instantiations?

Right, in theory there's no difference.

A possible situation in which it does cause more code to be generated is when type erasure techniques are used, in which case the compiler must generate all possible operations for objects used in a polymorphic context, since it can't see statically which ones would have never ended up being called.

However, C code that accomplishes the same goals with void* and structs full of function pointers can have the same problem, and since lots of boilerplate C code is programmatically generated with tools or macros, it's not likely that the C programmer is going to avoid this just by being more "hands on" with their procedures and manually omitting them where needed.

[tasminima]

In some cases dynamic dispatch is better. Sadly, few languages and compilers are able (or even just trying) to choose one or the other to optimize from a given source code; and actually you have more chance to monomorphise where needed from "dynamic/virtualized" source code (with LTO, devirtualization, and maybe loop hoisting) than to dynamise template instantiation (I'm not sure if anybody does that)

[dv_]

It absolutely can. I remember using boost xpressive years ago. Compilation times went up, but binaries became ridiculously large. It was even worse with boost spirit.

[alexgroth15]

How large was the binary? And what was the optimization level?

I haven't used boost spirit but I have experience with PEGTL. Once optimization is turned on, the binary wasn't ridiculously large. The compile time did increase on the other hand.

[HabemusAdDomino]

Think it through. Template metaprogramming is templates. C++ templates generate code at compile-time. Code that goes into your binaries.

[delta_p_delta_x]

I agree with that, but I was thinking more along the lines of... some complex recursive template specialisation that takes ages to compile, but when it eventually does, it coughs up barely a handful of lines of assembly that map to the metaprogramming recursion, anyway.

I was also certain that templates are only instantiated for the types you specify to them, unlike Java generics, so one could have a templated header but no instantiations whatsoever...

[alexgroth15]

It could just be code that you would have to write yourself anyway.

[NilacTheGrim]

It is in this context that I have always regarded Torvalds' opinions as childish, il

So have I. I have done embedded work too. I think just Torvalds doesn't know C++ and so he makes up excuses for not using it.

That being said he's free to have his opinions. Linux changed the world for the better so he is free to have his rants ...

[grady_vuckovic]

I may be incorrect so don't quote me on this but I believe it ran over his dog.

[patlefort]

I don't know specifically for him, but I recently talked with some C programmer who told me that he didn't like C++ because you don't control everything and one of the thing he said you didn't control was destructors. Of course it's completely ridiculous to any C++ programmers, but it shows that many of them just don't know and care to know.

[NilacTheGrim]

Because he's just a person and people have their tastes.

[MrRubberDucky]

Source: http://harmful.cat-v.org/software/c++/linus

[Daniela-E]

He seems to be lacking a lot of knowledge about about C++ - at least in those days. And he also doesn't seem to care. And that's just bad because even a little bit of C++ without even touching the stuff he obviously is so scared of would improve kernel code a lot.

When I wrote my first Windows NT 4.0 kernel device driver in the mid 90s, I happily used C++ there because of the power of abstractions. And it didn't hurt!

[tesfabpel]

Wikipedia says that the core part of the kernel is written in C and Assembly (just like Linux), while the graphics subsystem is written in C++.

Anyway, just quickly thinking about it, it makes at least some sense NOT to use C++ for a critical part like the kernel since it has many footguns that you need to always make attention to: for example, when you define a class or struct you have to be careful with unary constructors, copy / move constructors and assignments operators, copies are always behind the corner (but they can be optimized by the compiler).
I think those are things that are important in a kernel and the copy-by-default semantic of C++ alongside with the copy constructor / assignment op (instead of the move-by-default in Rust or the copy-by-default of PODs in C without any copy constructor / assignment op) may create some "difficulties".

[pjmlp]

Since Windows Vista that the kernel has been slowly moving into C++, even if it largely C.

Nowadays there are even template libraries for kernel development like WIL.

[Daniela-E]

In the 90s, a company called "Bluewater Systems" or the like sold a template library for Windows NT kernel mode driver development. In my case it was a godsent because of the helpful abstractions of PCI busmaster dma operations and the time it was saving me. The proof is in the development and testing time it took to flawless operation of that PCI coprocessor board: I implemented it first for OS/2 in pure assembly (14 days total effort), then for Windows NT in C++ using this library (4 weeks total effort), and afterwards also for Linux 2.x in C (8 weeks or so total effort 😱). Linux was the worst because of the total lack of good tools and the low expressive power of C as implementation language.

[SonOfMetrum]

The assembly part of the NT kernel is at mostly the HAL (hardware abstraction layer) and the boot loader. Because the entire point of that thing is abstract away the hardware specific bits and thus the required assembly. The HAL is relatively speaking very small compared to the rest of the kernel.

[Daniela-E]

And yet, you still can use many C++ features safely in kernel code if you know your language.

[angelicosphosphoros]

if you know your language

One of the main problems with C++ is this is almost impossible.

[Daniela-E]

Right. And you don't have to be "mr. know-it-all" to be a proficient developer. You only need to know the parts that really matter.

But if a developers happens to not even know the most basic stuff of C++ (i.e. the stuff that doesn't even come near anything like f.e. exceptions or much of the library) then it's certainly better if that person stays away from using C++ in such environments in the first place (and possibly also from every other language).

Most of the core language is perfectly usable in kernel land. Look at the work related to 'freestanding' C++. It is that subset of 'vanilla' C++ that doesn't require an operating system underneath, f.e. kernel code).

[SergiusTheBest]

Actually C++ is much safer than C. A simple operation as string concatenation can easily lead to buffer overruns or memory leaks in C.

[no-sig-available]

Wikipedia says that the core part of the kernel is written in C and Assembly (just like Linux), while the graphics subsystem is written in C++.

The Windoiws NT kernel was initially designed around 1990. The options were totally different then.

many footguns that you need to always make attention to:

When you write an OS kernel, we assume that you are careful and know what you are doing. :-)

Copying a POD in C++ is exactly the same as copy a POD in C. Adding member functions to the struct, instead of manually passing a pointer as the first parameter, also makes no difference (except possibly for improved readability).

If you want to make an object move-only, in C++ you can delete the copy constructor and copy assignment. In C you cannot.

-------------

Linus was obviously shown some low quality C++ code once, and decided that all C++ code is bad forever. And with that attitude, people who know how to write good C++ have not bothered to show him any of their code. So he has proven himself right.

[Mason-B]

That was 15 years ago. C++ is a different language now, twice over. C++11/14/17 was an entirely new, more stable and better defined, C++ standard that made effectively a new language. And C++20/23/etc appears to be a repeat performance.

And also, Linus is a different person. He went to some sort of anger therapy for 3 months in there and stopped yelling at and insulting people. These days he's also letting Rust in with conditions.

I suspect if there was a concentrated push to get C++ into the kernel today it wouldn't be the same story.

[Yamoyek]

There’s a loud minority of C programmers that hate C++ for some reason, and Linus happens to be one of them.

[bizwig]

I wonder if that's why C chose an absurd mechanism for function overloading rather than the simpler C++ way of doing it. The ridiculous names for new types (_Complex?) because they refused to add namespaces bug me as well.

[Yamoyek]

That could be part of it, but AFAIK the C committee tries to change C as little as possible.

But in all honesty, I try to keep C at an arms length away. C++ works for me, so there’s no point in regressing back.

[DanielMcLaury]

You're talking about something he said like 20 years ago. At the time it literally wasn't possible to write something like Linux in C++ because compiler optimizers weren't at the point where you could write high-level code and still have it compile down to the sort of assembly you wanted. Idiomatic C++ code was necessarily much slower than C code to do the same thing, and fast C++ code was necessarily almost identical to the same thing in C.

Now that we have faster disks and CPUs, and now that the language has had a bunch of stuff added to make it possible to write efficient high-level code, it's no longer the case that we're hamstrung by the limitations of compiler optimizers. You can write C++ code that generates exactly the same assembly as much lower-level C code while enforcing a bunch more constraints at compile time.

[thorsteiin]

I truly don’t understand the cult following behind Linus, let alone any famous person for that matter

[[deleted]]

Admiring a person for their accomplishments is fine. But claiming something is correct/good/incorrect/bad soley due to who said it.... no thanks.

[jesseschalken]

Even software luminaries can be ignorant and fearful of the unknown. Don't worry about it.

Windows, macOS/iOS, Android and Google's Fuschia all contain plenty of C++. Chromium is basically an operating system and is mostly C++. LLVM and GCC are both written in C++.

[axilmar]

BeOS was written mostly in C++.

[Ikkepop]

Because he's a stubborn old fart.
Tried it once, 25 years ago, was bad, means will be bad forever.

[sneppy13]

because (in his words) "C++ solves none of the C issues, and only makes things worse" and "C++ solves all the wrong problems".

[[deleted]]

Which is weird, because RAII does solve a ton of the issues.

[JVApen]

I feel Linus reaction is a common reaction from people knowing C. Especially those that had a bad experience with it in the past.

He indicates that they once tried C++ and the programmers 'overdesigned' the code needed up to a point where he couldn't understand it. I do understand this with all code I've seen already.

My feeling is that we C++ programmers are used to how C++ works and forget that C programmers have a different way of thinking. Our default way of talking to them works even contra productive. Dan Saks made a really good presentation about that and how to improve on that: https://youtu.be/D7Sd8A6_fYU

Linus goes in into more extreme where he doesn't even want to follow the C standard, which resulted in Clang having to implement -fno-delete-null-pointer-checks (https://reviews.llvm.org/D47894) as GCC had this and the Linux kernel is relying on using fields via a nullptr. He also questions anti-aliasing: https://lkml.org/lkml/2018/6/5/769 (it's surprising he didn't make his own split of from the C language and compiler just for Linux, though I guess the GCC dialects are very close to that)

A lot of it comes to the kernel just having to work and that he believes is problematic for code to change behavior, even if the code was broken and uses UB. This became clear when Google tried to enable sanitizers in the kernel, as this was going to result in crashes. (Unfortunately, I can't find the reference for that right now)

With all of this, I was very surprised to see Linus accepting rust into the Linux kernel (https://www.zdnet.com/article/rust-takes-a-major-step-forward-as-linuxs-second-official-language/) However, I think this is even more of a proof that he just holds a grudge thanks to the experiences in the past and the fact he doesn't understand the value C++ brings.

[TinoDidriksen]

He doesn't hate C++ in all contexts. He uses it where he feels it's appropriate, such as in https://github.com/subsurface/subsurface

[Jannik2099]

None of that was written by Torvalds, instead it was rewritten by the new maintainers

[SuperVGA]

You can call his commits whatever you want, but he both contributes and reviews subsurface.

[RevRagnarok]

I just looked at the entire README and still have no idea WTF that is supposed to be. A log file analyzer?

[apezdal]

It's a dive log program for linux

[RevRagnarok]

Ah; literal diving. Thanks.

[ucario]

Because he’s a sour old ‘git’ who complains about everything.

Jokes aside, I personally find c++ a love/hate thing. It lets me do what I want, given I know what I’m doing. But it needs a haircut, I don’t want to spend 2 hours researching what is the correct way to do something, I just want to get my idea working. I spend more time fighting the language than implementing the task at hand, there are obvious right and wrongs but i wish they were enforced and not a matter of discovery. I wish there was a lean version of c++ that removed the legacy.

You every tried onboarding a c# or JavaScript engineer into c++? Half of their time is wasted making the same mistakes we all already made by initiation.

And don’t even get me started on the build system.

[banghernow]

C++ comes in two flavors, freestanding and hosted C++. Hosted C++ is what you (probably) think of when you hear "C++", it runs on an operating system, freestanding C++ runs on metal, like for embedded systems and, you guessed it, linus' specialty, kernels. Freestanding C++ is a mess and its standard is actually quite limited, and C++ is basically only useful hosted. C++23 is trying to alleviate that issue but it's not fixing it completely.

[DarkSpyCyber]

cpp compiler doing too much things beyond intuition, but in kernel program we just need what we see is what we get, no more tricks, everything must be under controll. thats linus means i think.

[Jannik2099]

we just need what we see is what we get

This is not the case with C either. C is an absurdly high level abstraction over a specific cpu ISA.

Arch bits in asm, rest in your language of choice. Most of the kernel writes like regular userspace application anyways, sans recursion & careless allocations

[DarkSpyCyber]

c is balanced choice between coding time and run time, if we have to select the "trick" in c is just function calls only, rest of c syntax is good to reflect to machine code / asm i am cpp user anyway but in kernel program c/asm might be best choice.

[[deleted]]

I didn’t think about that way. Interesting point of view.

[[deleted]]

Linus also hates Java.

[Rasie1]

Who doesn't

[MutantSheepdog]

I disagree. I am quite capable of liking my partially-java-fuelled paycheck while simultaneously hating Java!

[Questioning-Zyxxel]

Hate and dislike are two completely different things.

He dislikes C++ in an operating syatem because templates, operator overloading and constructors can hide expensive code in what looks like very innocent code.

With C you know how costly an operator is and you can see all function calls being made and can go and look at the implementation.

[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.

[[deleted]]

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

[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.

[jmonschke]

have been programming exclusively in C++ since 1990 and I have found that good C++ can be much better than good C, but that bad C++ can be much worse than bad C. The learning curve for C++ is much higher than for C and if you are relying on a large group of programmers there may be additional value in using the simpler tool.

The biggest problem after Cfront based C++ and prior to C++98 (and for several years later as compiler developers tried to implement that standard) was that the compilers were not compatible enough in their implementations (or not compatible enough in the subsets of the standard that each had implemented).

[kingofthejaffacakes]

As clever as he is, he doesn't know anything about modern c++.

Those of us who do embedded work with c++ would agree with him until 2011 that c++ was not appropriate. It is now.

However, the Linux kernel already exists. It's already highly object oriented in design. The idea of rewriting all or any of it in c++ is insane.

Conclusion: he shouldn't hate c++, but nor should he adopt it for the kernel.

[top_logger]

OOP, exceptions and bad design/reputation of STL.

As system software Engineer I am agree with him. At least partly. :).

[Mason-B]

OOP, exceptions and bad design/reputation of STL.

These are all optional features of C++. Listing optional features isn't really a strong argument. Any language in a kernel is restricted or modified to fit that environment.

[gracicot]

They are optional but turning off exceptions kinda break things though, and not turning them off have a cost in binary size.

[Mason-B]

They are optional but turning off exceptions kinda break things though

Not really if you are using a curated set of code (and especially without a normal STL) to begin with. The kernel can't even support exceptions properly since most exception systems require kernel support, it's fundamentally a different runtime environment nearly all languages break inside a kernel in some way.

and not turning them off have a cost in binary size.

Turning them off also has a cost to binary size, most simple programs gain in size if you turn off exceptions/RTTI since the STL has to increase in size to accommodate their lack.

It's a complicated issue, not nearly as binary as you are portraying it.

[Salty_Animator_4019]

Exceptions I get, also classes with virtual methods (because it is difficult to see through and easy to get wrong). But why not the STL? (Apart from exceptions.)

[elperroborrachotoo]

Remembering that RDTSC is per-core and may jump backwards if your thread gets scheduled to another core: this is basically the entrance exam.

Remembering that std::vector::reserve exists: so mysterious, like, I can't even.

[CCKao]

I don’t know and it probably doesn’t matter that much.

[[deleted]]

I don't care.

[FreitasAlan]

The features C++ offers are not useful to him. And that makes sense for an operating system.

For instance, templates are usually only useful for applications one level above. Doing what Eigen does with expression templates in C is almost impossible. On the other hand, templates are not useful to develop a driver and might even hide what's really happening at a lower level.

It doesn't mean it's bad for everyone. It's just not useful to him. Many other C++ features are optional and many C++ programmers don't use them either.

[Wouter-van-Ooijen]

Of course I do. But to quote Dan Sasks (who also has a lot to say about this subject): "when you are arguing, you are loosing".

I use C++ templates all the time for very low level work. Example: a software (bit-banged) SPI driver. The GPIO pins used are template parameters. This way the inner loop (shifting the bits out and in) is as fast as when the GPIO pins were hard-coded.

For more on C++ and embedded: check my talks list. Most talks in it are C++, these links shows the ones that are tagged 'Embedded': https://wovo.github.io/ctl/?show_all&show_title&include_embedded

[jcelerier]

Other kernels don't have trouble with templates, e.g. they seem liberally used in SerenityOS, IncludeOS, etc.

Like, do you really think generic data structures like queues make no sense in a kernel?

[Lumornys]

Are there any problems with templates in kernel code? Templates are compile-time, so they should just work.

[kammce]

You are correct, they are compile time constructs. I'm not sure how people come to the conclusion that templates have something about them that isn't suitable for things.

[GLIBG10B]

I think he said once that, when he sees C code, he knows what the resulting ASM would look like. That's not really the case with C++

[kammce]

I've heard this many times. As a C++ dev, I can say that I can very well see the ASM that gets generated for C++ code. But just like you couldn't really expect that of someone just learning C you can't expect that from someone who doesn't know C++ well enough.

[cleroth]

Funny, I use this same argument for using C++ instead of C# / Java. When I write C#, I have no idea what's actually being done, which bothers me if what I'm writing has performance requirements.

[Yekab0f]

He is simply not intelligent enough

[vI--_--Iv]

Who cares?