I heard about this note from Linus Torvalds from David Wolever yesterday. Here’s Torvald’s opinion of C++.
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 crap 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.
Well, I’m nowhere near as talented a programmer as Linus Torvalds, but I totally disagree with him. If it’s easy to generate crap in a relatively high-level and type-safe language like C++, then it must be child’s play to generate crap in C. It’s not fair to compare world-class C programmers like Torvalds and his peers to average C++ programmers. Either compare the best with the best or compare the average with the average. Comparing the best with the best isn’t very interesting. I imagine gurus like Bjarne Stroustrup and Herb Sutter can write C++ as skillfully as Linus Torvalds writes C, though that is an almost pointless comparison. Comparing average programmers in each language is more important, and I don’t believe C would come out on top in such a comparison.
Torvalds talks about “STL and Boost and other total and utter crap.” A great deal of thought has gone into the STL and to Boost by some very smart people over the course of several years. Their work has been reviewed by countless peers. A typical C or C++ programmer simply will not write anything more efficient or more robust than the methods in these libraries if they decide to roll their own.
Torvalds goes on to say
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
I’ve had the opposite experience. I’d say that anyone wanting to write a large C program ends up reinventing large parts of C++ and doing it poorly. The features added to C to form C++ were added for good reasons. For example, once you’ve allocated and de-allocated C structs a few times, you realize it would be good to have functions to do this allocation and de-allocation. You basically end up re-inventing C++ constructors and destructors. But you end up with something totally sui generis. There’s no compiler support for the conventions you’ve created. No one can read about your home-grown constructors and destructors in a book. And you probably have not thought about as many contingencies as the members of the C++ standards committee have thought of.
I disagree that writing projects in C keeps out inferior C++ programmers who are too lazy to write C. One could as easily argue the opposite, that C is for programmers too lazy to learn C++. Neither argument is fair, but I think there is at least as much validity to the latter as there is to the former. I think there may be a sort of bimodal distribution of C programmer talent: some of the best and some of the worst programmers use C but for different reasons.
I do not claim that C++ is perfect, but I’ve never had any desire to go back to C after I moved to C++ many years ago. I’ll grant that I’m not writing my own operating system, but neither are the vast majority of programmers. For my work, C++ is as low-level as I care to go.
or considering?
Well, let’s see. It’s well known that Google employs Python’s creator Guido van Rossum, and some Java heavyweights such as Joshua Bloch. Google App Engine supported Python first, Java later in response to popular demand (http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html), C++ not at all. Android is primarily Java-oriented (http://developer.android.com/guide/basics/what-is-android.html). That’s a lot of weight, and increasing weight, put behind languages other than C++.
Similarly CERN (who runs LHC) has adopted a Java-based solution for their messaging backbone (http://hardware.silicon.com/desktops/0,39024645,11023796,00.htm), and deployed a pretty serious Java infrastructure (http://cerncourier.com/cws/article/cnl/31107). Their partners at LBL are helping them push Java for scientific computing (http://acs.lbl.gov/~hoschek/colt/). Again, that’s a lot of weight behind a language at C++.
I’m sure Google and CERN will continue to use C++ for years to come, and benefit by it. I’m equally sure that the C++ code as a percentage of total code will continue to drop. There are simply better options available.
I assume that when we’re talking about Google, we’re talking about the Search Engine, not the App Engine, Android, etc. Google people use many languages to achieve their goals, but this does not mean they are “moving away” from C++.
Remember what language they’ve chosen for Chrome.
“The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun’s “classic JVM” which was written in C).”
http://www.research.att.com/~bs/applications.html
I’ve downloaded the Java SE 6u18 sources and it’s true: 775 .hpp vs 30 .h files and 686 .cpp vs 18 .c files) for the hotspot part.
This is the latest Java VM available, and again, C++ is the “chosen one”.
Many say that Java wants to compete with C++, this could be true, and if so, it’s very ironic that it’s core is written in this language (i’m not saying it can’t compete with it, Hotspot seems to be very fast, i’m just saying it’s ironic).
This is another example of use of this wrong tool…
(i’ve missused the italic in my previous post)
“The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun’s “classic JVM” which was written in C).”
http://www.research.att.com/~bs/applications.html
I’ve downloaded the Java SE 6u18 sources and it’s true: 775 .hpp vs 30 .h files and 686 .cpp vs 18 .c files) for the hotspot part.
This is the latest Java VM available, and again, C++ is the “chosen one”.
Many say that Java wants to compete with C++, this could be true, and if so, it’s very ironic that it’s core is written in this language (i’m not saying it can’t compete with it, Hotspot seems to be very fast, i’m just saying it’s ironic).
This is another example of use of this wrong tool…
Oh, by all means let’s move those goalposts some more. You asked for evidence about what Google was doing. I gave some regarding some of Google’s most recent and highest-profile projects. Chrome has strong dependencies on many C++ libraries, and the goodness of code reuse could quite legitimately have outweighed the badness of the language. What they do on projects that are so encumbered with dependencies tells us much less than what they do on projects not so encumbered, so please don’t cherry-pick that one example and pretend it proves your point.
I said Google will still use C++ for many years. I also said that the percentage of their code written in C++ would drop. I think I’ve shown far more evidence to support that than you have shown to support much of anything. Please stop holding others to an infinitely higher standard of proof than you hold yourself.
I asked you for evidence that some of my examples are moving, and in the case of Google, I asumed from the begining we where always talking about the Search Engine. So if you can get me evidence that the Search Engine is moving away from C++, then I’ll say you’re right, and we could say Google is moving away from C++.
For the LHC part, check out this link:
http://www.youtube.com/watch?v=bSEv4vF5CTs
(Marjoire Shapiro talking about the LHC)
Time: 0:41:44 —> We have a multipurpose C++ framework…
For the Chrome part: There are many good libraries in C++ you can use, so come & use this wrong tool, Google did…
I’m still waiting for the java or python version of Chrome or Firefox…
What we’ve learned so far is:
– C++ with good dicipline, good libraries and tools allows you to write very good programs.
– C++ has allowed the existance of very good software, and continues to do so (JVM, Chrome, many many games you currently play, etc).
– and yet: C++ is always the wrong tool…
Who ever said C++ was *always* the wrong tool? Not me, that’s for sure. In fact, I’ve gone out of my way to point out that C++ is sometimes the right choice despite its deficiencies. Really, you didn’t have to descend into constructing strawmen and similar trolling tactics like this. We could have simply agreed to disagree, like grownups, but I see now that only one of us is capable of that. Good luck getting a career.
I never said you said so, but the other ones did (including Linus).
What you said was:
“On the other hand, there are good reasons why even some of your examples are considering or moving toward alternatives. They believe, and not without reason, that even if their programmers have created decent software using C++ in the past and can continue to do, those same programmers can be even more productive in other languages.”
But:
– You could not prove any of my examples where “moving away” from C++.
– Somehow you know what “they” (decision making people at the companies whose products I mentioned?) believe, and this is that the current C++ programmers they have can be even more productive in other languages. I don’t think this is true.
In fact, I’ve shown you that many of my “examples” are actually embracing the language.
Besides, I’m no fanatic. I like Java very much and I want to learn how to use Python.
For the agreement part: My first post was an agreement to your post, because you where right. But after that you could not hold your statements, so I could not agree with them.
“so please don’t cherry-pick that one example and pretend it proves your point.”
This is the begining of the tone raising (from your part).
Google hires Guido and then get him to work on a code review tool. Wow! Just Wow! I think he’s just another celebrity employee there. A honeytrap for graduates.
I think Google also pays Guido to work on the core Python language 50% of his time…
http://www.linuxjournal.com/article/10185
Having the experience this weekend of picking up somebody else’s C++ module and trying to get it to compile, let alone run, I must agree with the wag I read in a related C++ forum who wrote,
I understand why STL is supposed to be useful and good and clever, but really ….
I cannot recreate the original build environment without essentially rebuilding an entire Linux system. I am not about to do that. I am, instead, going to write the new code afresh, hoping that it does all the old code was supposed to do.
Alas.
John, I think you miss Linus point. He isn’t really saying that C is better than C++ in a vacuum. He is saying that those abstractions you typically build in C++ and which C doesn’t easily let you build can much more easily be built in a host of other languages. When those languages don’t offer enough performance you can use C. You don’t need C++. git which sparked this debate is a good example. git is not a large monolith built out of C. It is small C components clued together by higher level languages.
For rapid development and high performance why not develop the application in Python and code performance critical parts in C? Why make the whole application in C++. C++ is a poor application development language and you end up reimplementing features from dynamic languages in C++ in a buggy and messy way.
The old days of C++ are gone. Boost brings C++ to a new era, the era of correctness, robustness, portability, simplification and performance. More and more C++ projects are using Boost. At our company, we use C++ for many things, but Boost is a must. Otherwise it’s impossible and all the bad C++ things appear. Boost makes C++ a very suitable languaje for general application development. C++ always needed Boost, and now it’s here, for the good. C++ without Boost sucks, C++ with Boost is very good and usable (and fast, btw).
I ened up on this site from a somewhat related topic – reversing a convoluted C++ application. In frustration I googled “C++ call tree clusterfuck”. That summarizes my opinion. For anyone that has ever looked at compiled C++ and the tangled mess inheritence, polymorphism, function pointers, etc. C is a great language because the program does basically what you tell it to do. In C++ you write things with almost blind faith that it’ll work the way you hope it does.
Linus wasn’t really comparing programmers, he’s examining the language. He rants a little about progammers, but IMO the core of his arguement is fundemental problems with the language. Comparing programmers isn’t really useful. It’s like comparing mathmatics in Roman numerals versus Arabic numerals. Mathematics is simply much clearer and more meaningful using Arabic notation. Latin is exceedingly clumsy for mathematics. I’d argue that C++ is similarly flawed. Sure you can run an empire with it, but that doesn’t make it less ugly.
Inheritance and virtual functions are mostly unnecessary.
I think you need to understand what Linus means and not a literal interpretation of his words.
His main point:
Linus: “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 crap 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.”
IMHO you could (counter)argue that “substandards” also exists in C but that is not the problem.
What he means is that C++ allows high-level constructs and these “substandard” guys (and others) are the ones that do not know how the constructs would be implemented “on the hardware”, so that they would not understand what their constructions would imply on the compiled code.
That is, if you know how the machine will process your classes, multiple inheritance etc.. IN DETAIL, you could use C++.
C somehow forces you know what will happen in detail (much more than C++). I think this what he means, that is, this is his main “theme”.
I was helping a physicist to modularize their C model code, and in the end we implemented a poor-man’s class system. It would be much easier to do it in C++.
C++ has a problem though for the inexperienced: design paralysis.
Torvalds has “C-hacker syndrome”.
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
I’m a C++-programmer and I’m trying to learn Java. The more I know Java the more I love C++. It seems that C++ is for real programmers and most of the other languages are for people who don’t know what they are doing. Just like Java. I hate Java and all the restrictions it has.
@Coder
That’s harsh. I have used both Java and C++ in mature projects, and really, both have their pros and cons. For example: build times!
@Coder
Well Java is a powerful language. Heard about Android? Where you need high dynamism and instant portability, C++ loses, and Java wins.
@Chila
Even on a PC, if you need a Java library, you download a JAR and that’s it. If it’s C/C++, you may spend quite a lot of time getting it to link with your code.
@QuantDev
That’s right. Java wins sometimes, and C++ sometimes. Nowadays with gcc and the Boost libraries, C++ use has become a lot easier. If the library uses Boost heavily, and compiles in gcc, portability is increased a lot. So the chances that doing:
– ./configure
– make install
ends in success is increased, and even more if the target system is Linux.
@Chila
“So the chances that doing:
– ./configure
– make install”
Getting the library to compile does not make it portable yet. It must also be useful for other code.
“even more if the target system is Linux.”
… which has a minuscule market share on the desktop.
@QuantDev
There’s source code portability and binary (intermediate) code portability. C++ can achieve the former, Java the latter. My response was related to your statement:
“if you need a Java library, you download a JAR and that’s it”
So even thou it will never be as easy and direct as downloading and using a jar, it can become very close nowadays.
If the operating system is GNU/Linux, the chances increases since gcc and boost are primarily targeted at this OS, but I have good experience in Solaris and HP too.
@Chila
“There’s source code portability and binary (intermediate) code portability. C++ can achieve the former, Java the latter. ”
Lack of binary compatibility has profound consequences for real world applications. Also, the source compatibility in C++ world is not universal (neither is binary compatibility in the Java world, mind you…). For example, there still isn’t a standard C++ 2D matrix class.
“If the operating system is GNU/Linux”
That excludes the vast majority of systems that people use.
“Lack of binary compatibility has profound consequences for real world applications.”
The majority of the programs you execute are not binary-compatible (your browser, your OS, etc.)
“Also, the source compatibility in C++ world is not universal.”
That’s the part that the standard and Boost are trying to solve, or better said, improve.
“That excludes the vast majority of systems that people use.” (linux)
Well, that’s changing a lot. Take for instance all the Android phones and all the servers there’re out there. Linux is growing very rapidly in general.
Every language suckssss!! Every OS sucks!! Every tool we are using day to day sucks!!
So, What is the point?
These are all just tools, Every thing must be used in it’s right place and it’s right time…
I love it when java programmers compare c to java. They probably don’t realize that java is mostly written in straight C with pure assembly when things need to be done better. Same concept applies to great video games too.
thats right folks–after java, c++ and all the other languages that came about from the bastardization of straight vanilla C have gone and long forgotten ansi c will still be here.
As I understand it, Java evaluates mathematical functions like sine and cosine in software, not using the functions baked into the processor’s microcode. I would expect that could have a significant impact on performance for some programs. Maybe it doesn’t matter for most code.
Wow, this thread has longevity. Of course, I’m continuing it.
Two points.
First, John wrote: “The set of C features not in C++ is small and mostly deprecated.” Actually, the history is a bit more complicated than that. It’s been more of a conversation than somehow C++ moving beyond C. There are things that have been put into C via C89 and C99 which were borrowed from the experience with C++, and, of course, with the ever increasing capability of hardware. An example of the latter is how to do random access of Truly Huge File Systems where you can’t know how many bits are in the handle which access them.
Second, it was MUMPS which reduced all arithmetic to strings, thus making all arithmetic portable across realizations. I think that may have been the spirit of Java in evaluating things in software. Still, what I find offensive about many people’s codes, no matter, is that they deliberately exploit peculiar libraries and don’t try to write code that’s portable. People’s buying into the GNU model as portable is really hypocritical, because there are not single realizations of that model: The model depends upon the version of the compiler, and to some extent the vendor.
I also have found that some gcc versions have optimizers which break code, and I only found these by executing the same numerical code on a Windows compiler for which I paid. (No, not Visual C.)
I’d say you are correct, John, when hardware now implements IEEE Floating Point nearly everywhere. I heartily wish, however, that we had grown up more about this and had widespread and standard libraries available everywhere for doing things like SVD and Cholesky decomposition and Warshall transitive closure. We don’t. Heck, it’s hard to find consistent and good libraries for doing great circle distances on unit spheres. Often better to write ’em yourself. That’s sad.
As someone already mentioned it is quite unfair to take this quote out of context. This was taken from a discussion where someone asked why the linux kernel isn’t written in C++ instead of C. As you can see when you carefully read this other quote “the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.” he is talking about _system-level_ applications like the linux kernel.
I think the C++ FQA (Frequently Questioned Answers) says a lot (see http://yosefk.com/c++fqa/). I have programmed in a number of languages includling Java, Python, Ada (yes, Ada), PHP, Ruby, Javascript, C and C++. I have also work with and managed software developers in these languages. There is one thing I can say without a doubt. Unless you have a team of bright people who are able to work really well together (and those two rarely go hand in hand), C++ will put you in a world of misery in the long term. Although perhaps Java not so much, other languages provide real programing constructs that act to help the developer achieve their goals. C++ is the opposite (and again I defer to much of the FQAs, but admit some of that is a little overly done). It is not a matter of how well YOU work with the language either. You will invariably be dealing with other people’s code you inherit as well.. Then you will truly know the pain of what someone else thinks is “great C++ code”. I am currently working on a project using C an C++. We are using Boost, although realizing its use is a mistake given the way it bloats are code/library size and the nearly 100 steps through boost code via signal calls and bind calls just to implement a frickin callback. Boost code is attrocious to look at, particularly when debugging a problem. Oh, and the “designer” of this system decided to use boost signals coupled with boost bind, only to spend over a week of time tracking down a bug where the signal was holding on to a bind object that was holding on to a pointer to an object that had been destructed. There wasn’t much thought (and perhaps didn’t seem to need that much, but oh the bite stings on that one) put into this aspect of things as it was nicely NEARLY hidden from the developer underneath the layers of obfuscation in Boost. We are working hard to remove Boost from our systems because it simply failed to live up to its expectations. I truly cannot say that about the other languages I have worked with.
Had I been there at the start of this aforementioned project, I would have realized the bad decision here — but the real interesting thing is how this developer simply feels this is “normal” development to spend that much time tracking down subtle bugs such as these. Portability has alwaya been an issue and ability to interface to any other language (except Ada under the gcc compiler system only) is non-existent. Compile time for C++ code is order of magnitude than other languages, which any manager worth his weight will tell you will have negative consequences on productivity as the project grows/matures.
Bottom line: it is easier to program in other languages to achieve the same thing with C++ but in a way that is just as or more efficient, with cleaner code that better communicates intent to other developers and has truly built-in constructs to help modularize, is more resilient to changes, with far less time spent on integration (or in C++ lingo: debugging). There is little reason these days to choose C++ for a project. I have to agree with Linus on this one.
….. For example, once you’ve allocated and de-allocated C structs a few times, you realize it would be good to have functions to do this allocation and de-allocation. You basically end up re-inventing C++ constructors and destructors…..
WOW! This shows little experience in programming in general. In C, you often use opaque types which provide TRUE encapsulation as opposed to C++. That is the details of the struct are in no way accessible to the client via the header file. One must create constructors and destructors, which I am sure is where C++ got its concept (just like C++ , although there the compiler will magically provide them for you even if you don’t define them). The fact is that C++ forces you to expose your implementation details to the client (accessible through #define private public — of course), which forces massive recompiles for things that shouldn’t. So developers get to enjoy orders longer compile times — greate for productivity! yippee!!!!
Instead of fighting between these arguments, people who believe in C++ can write an OS kernel in C++ which is much faster and robust than the existing linux kernels written in C.
This will be a direct proof to any person who says a language tool is not worth enough of the current needs.
@kiran
Even thought I’m not agreed with torvalds points about C++, but you are getting the matter wrong. I’m a C++ programmer and never touched C.
C++ is not faster than C !! Some times even slower. But this doesn’t mean C++ sucks and C rocks!!
I chose C++ because I need performance and I’m an OO-programmer, plus it gave me an abstraction layer over C which means I can focus on my problems instead of challenging with the language itself.
To me C is like a higher-level Assembly language which is also very portable. And since a kernel is a low level program I believe here C has very advantages over C++.
Right tool in it’s right situation. Both C and C++ are great languages in my opinion.
@babaei In many places C++ is faster than C, compare std::sort vs qsort
for example. In many places, the performance cost incurred in C++, like for instance, the use of virtual dispatch, is the same or better than done in C. In many cases you need stuff like this in your C program, and one ends up writing lots of inefficient and buggy code to do the same thing C++ can do faster an cleaner.
@chila
Yeah, of course C++ rocks. but:
1. All those std::* vs C equivalents performance depends on your compiler implementation, that’s not the language itself.
2. Even if Scott Meyers rights about std:sort is being faster than qsort (I didn’t test that myself) I believe C++ is not appropriate for developing a kernel.
Virtual Functions, Inheritance and VTable Access makes C++ slower than C
3. Usually a kernel programmer is not a novice programmer who writes lots of inefficient and buggy code. They code for stability and performance and they know the target architecture better than any other programmer.
4. A low level programmer needs access to bare-bone without any limitation or abstraction and they don’t need what C++ offers because of that.
Of course C++ is a general-purpose programming language and you can do everything from developing a kernel to writing a complete website in C++. But in some situations there are better choices.
Again I’m a C++ programmer and I chose C++ over C for so many reasons and benefits, but if I were a kernel programmer without doubt C was my tool over C++ (I even chose C++ over ASP.NET, Perl, Python, Ruby and PHP for developing websites, now I’m doing all my websites using C++/Wt instead of the mentioned languages.).
@babaei
1. If a compiler does not implement inlining, it shouldn’t be used.
2. Nobody is saying that C++ is suitable to develop a kernel, although it is being used: http://www.l4ka.org/65.php
“Virtual Functions, Inheritance and VTable Access makes C++ slower than C”… to what in C? if you end up using indirections (pointers) to do things virtual functions can do, in many cases using them should be equal or faster, and cleaner.
4. Some abstractions are useful, like classes. Couple that with templates and inlining and good performance is assured. Some features aren’t, like exceptions, since it’s very hard to fully know all the exceptions a function can throw, and you should in highly critical systems development.
Templates and inlining do not assure good or even decent performance. Excessive inlining can carry a cost in terms of intruction-cache pollution, TLB misses, degraded branch prediction, etc. Many times I’ve seen that cost outweigh the benefit of avoiding a simple function call. Templates have exactly the same drawbacks, and in my experience those who rely on a template-oriented program style (as unfortunately recommended by many books and practically required by many libraries) are even more likely to pass the point where the costs outweigh the benefits.
Templates also cause exposure of implementation in the header file (if using the typical model of writing templates) and cause excessive compilation times for the code. Libraries built from overuse of templates can also be very bloated. Templates when used at deep levels (3 or more) of inheritance or dependency can become fragile and break from the simplest of changes to the base templates.
Templates can often and easily get out of control in C++ and can lead to a point where a team trying to be Agile spend more an more time servicing the delicateness of the code to fix bugs or support updates than making forward progress on actual new features themselves.
@codeguru What’s normally done is to use templates at lower levels, and interfaces/abstract classes at higher levels. If you do not want to expose your implementation, hide it behind a opaque pointer. This will make your class easily swappable, which is needed when implementing assignment operator with strong (transactional) exception guarantee.
Compilation times are being improved in compilers, specially in clang.
Used with care, templates become a very useful abstraction tool.
The biggest problem with C++ is that people spend a lot of time messing with the language instead of spending that time working the problem.
Linus is blunt and he is correct. He has a real world example. A kernel used world-wide by millions of people and maintained by thousands. I spend a fair bit of time in that kernel. The style of coding has resulted in a very fine product that has been well tested, peer reviewed and analyzed by coverity and others.
When compared to commercial products the kernel is well ahead of the industry in robustness and maintainability. This is a strong example why C is better than C++.
Do you have a first hand example of a system of similar complexity to compare?
@bill
very fine product !!!!!!!
Even Linus calls Linux ‘bloated and huge’:
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/
That’s why I migrated to BSD long time ago!!
@bill
“When compared to commercial products the kernel is well ahead of the industry in robustness and maintainability.”
Can’t comment on maintainability, but Linux is not the only OS with a stable kernel. Are they all written C? I’m not sure.
Also, a language which is very good to write an OS kernel in, does not have to be the best choice for a language to write an application, or a numerical library. E.g. most pricing libraries used by banks are written in C++ or Java, not C.
All object oriented languages are designed to be user friendly but C as a procedural programming language which is system friendly and is treated as an alternative to assembly language.
So to develop low level code obviously one needs to choose a system friendlier language than a user friendlier language like C++. So linux knows this fact :)
@kiran completely agreed with you on this one.
“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 crap with it.”
This comment does not just say: “C++ is horrible for kernel development”, this more looks like says that C++ is horrible in general. I think he’s going too far, since many ones choose C++ because it’s easier to program using abstractions like classes, virtual dispatch, templates, than having to “simulate” them with macros and obscure techniques. Let’s remember for example, that the JavaScript V8 engine, Google Chrome, Mozilla Firefox, Java Hotspot VM, etc etc are all in C++. Is this because the authors like “uglier” languages?
That would be weird.
Let’s remember Torvalds that C has also many substandard programmers, and that really utter crap can be made with it.