The Death of Modern C++

Note: I updated the view counts for the videos mentioned. These are current as of 12/9/18.

A friend of mine sent me slack message asking for my opinion of an article he saw on Reddit. In a nutshell, the author makes the case the C, C++, and by extension, Modern C++ are dying languages and that they’re dying because they’re unsafe languages. Like COBOL, the author says, they are a dying breed and destined to be consigned to the scrap heap of programming languages in favor of “safe” languages (my paraphrase of his thesis).

You can read the full article here: C and C++ are dead like COBOL in 2017.

To start with, the comparison between COBOL and C++ is a bad one. C++ is a general purpose, Turing complete programming language and COBOL is not. They live in completely different domains and solve completely different problems sets so any comparison in usage characteristics falls apart rather quickly.

But in general, yes, I agree with his basic premise that the use of C, C++ and Modern C++ is declining in an ever expanding universe of languages but not for the reasons the author subscribes.

I think lassitude is a more reasonable explanation. With complexity as an accomplice.

In the article, the author says, “However, I realize that security, while of vital importance to me, is of relatively little concern for most software developers.” He then goes on to argue that the decline of C++ is because it’s an unsafe language. Both arguments are in conflict with one another and cannot be true at the same time.

The decline of C++ is, I think, not because of security. It is true that most developers generally don’t concern themselves with security. But that also means that they’re not going to walk away from C++ for those reasons. You can see the evidence of this on YouTube. Both of my talks on secure coding in C++ at CppCon 2018 got just over 7K views combined.

The talk on nano-coroutines, 16K views.

Embedded (where C++ gets little vendor support), 7K views.

Metaclasses, 33K views.

Modern C++ Design, 16K views.

Part of it can be explained by me being an relatively unknown speaker. But, largely, I think software security is not a particularly sexy topic. Ask yourself how many security talks have there been at C++Now or CppCon in the past 5 years by well-known speakers? A hand full, maybe.

Compare that to the number of talks on: Template Meta programming, Concepts, Co-routines or Data Structures. A dozen or more on each I would expect.

Developers don’t care about the security of Modern C++.

But they should and I’ll make the case as to why further down in this post.

Instead, what they care about is how easy C++ is to use and the cool things they can do with it. The reason for the decline of C++ is that it’s a hard language to master. And, we’re making the problem worse as we add more and more stuff to the standard that increases complexity but has specious value at best. That makes the jobs of everyday developers harder, not easier..

I had an interesting conversation with Bjarne at CppCon this year and he makes an excellent point about having language standards that are top heavy and overloaded with dingle-balls for experts (my words, not his).

From his paper, Remember the Vasa!:

“The foundation begun in C++11 is not yet complete , and C++17 did little to make our foundation more solid, regular, and complete. Instead , it added significant surface complexity
and increased the number of features people need to learn. C++ could crumble under the weight of these – mostly not quite fully-baked – proposals. We should not spend most our time
creating increasingly complicated facilities for experts, such as ourselves.”

Having said that, it’s generally incorrect that other languages are “safe” while Modern C++ is “unsafe”. JavaScript has lots of ways to write unsafe code. Same with Java & .Net. If you don’t validate the data you’re operating on or verify the sender, for example, no language will save you.

The reason that people are migrating away from C++ to Rust, Go, D, Python, JavaScript, et al is that these are more discrete languages that have fewer moving parts and are easier to master.

Basically, we’re lazy as a species and we’ll surrender control for comfort.

Is C++ a safe language?

Unsurprisingly, I get this question a lot including several times at CppCon this year in my security talks and again in the software security panel discussion. My answer is, yes – if you know what you’re doing. The problem is that most of us don’t and each new release of the standard makes that problem worse.

If we want to keep C++ from becoming a niche language for experts, we’ll have to address its complexity and how we use it. In the same way that energy in a structure under stress migrates to the weakest points, vulnerabilities migrate to the areas of greatest complexity.

C++, and by extension Modern C++, is a well defined language and I have nearly thirty years of experience with it. I also have a security background using it. That makes it a “safe” language for me because I know what I’m doing. But, even I find it challenging to keep up with the undefined behavior in the standard and, not being a language lawyer or compiler designer, even I have a hard time just decoding the standard itself.

What will make Modern C++ a “safer” language is when we stop increasing its surface complexity. And by the way, that’s when more developers will come back to Modern C++ because its power and flexibility are unrivaled in the history of computer science.

And what about C++ developers not caring about security?

That’s beginning to change. As the financial body count from breaches rises and as more heterogeneous, unrelated systems become incidentally interconnected via the internet (think jets, autonomous vehicles and power plants), the visibility of software security is beginning to rise. This year at CppCon, for example, there were seven talks and two panels related to software security accounting for almost 40,000 views on YouTube.

And secure software should come to the forefront. The same principles that make code safer also make it simpler, easier to reason about and more maintainable.

When it comes to low latency, scaleable software that runs close to the hardware, Rust, Go, .Net, Python, Java and JavaScript will never cut it. Modern C++ is here to stay because it out classes everything else on the market for the problems it’s designed to solve. Our goal now should be to make it simpler & safer and educate engineers on avoiding its sharp edges. A good place to start is here: C++ conference talks and interviews on software security.

One final note: .Net, Java, and most JavaScript interpreters – the languages that are considered “safe” – are all written in C and C++. Some of the other languages considered “safe”, like Go, also started life being written in C or C++. Any language written in an “unsafe” language cannot, by definition, be considered “safe” because the vulnerabilities of the underlying language become yours when you use it. You just don’t have any viability into them.

And COBOL is hardly at death’s door. They added Object-Orientation to it in 2002 and the last standards update was in 2014. In 2012, Computerworld did a survey and found that 60% of the world’s businesses used COBOL for new development and that for those companies, COBOL was used more often than C++, JavaScript or .Net.

Not bad for a dying language that turns 60 next year.