The state of C++

Last July, the Carbon programming language was officially announced at the CppNorth C++ conference in Toronto, Canada. Carbon is presented as “an experimental successor to C++” and was started as an open-source project, by Google no less. Wait... Google is going to create a C++ successor? Until recently, the company was heavily involved in developing the C++ language and engineering the Clang C++ front-end for the LLVM compiler. With tens of thousands of engineers within Google working on billions of lines of code, choosing the path of a completely new language seems rather bold.

Why would a huge company such as Google venture into such a daring project? Well, it’s a symptom of the state and development of C++. For those who haven’t caught up with the language’s evolution in the past few years: there have been some major discussions. Of course, having discussions is the whole point of the C++ committee meetings, but one topic has been popping up again and again without settlement: whether or not it’s worth improving language design at the cost of backward compatibility.

Leaner governance

C++ has been around for about forty years now and is being used to create performance-critical software all over the world. After a period of relative quiet following the initial ISO standardization in 1998, the committee managed to steadily introduce great improvements every three years since 2011. As a result, the language has grown quite different from what those of us old enough used to work with in the nineties and noughties. The addition of features like concepts, ranges and modules in C++20 alone pack a powerful punch.

At the same time, though, the C++ language evolution process is known to be extremely challenging. The weight of carrying decades of technical debt while maintaining backward compatibility is substantial – too much for some, it seems. Trying to add a significant language feature may cost up to ten years of lobbying, discussions, reviews, testing, more reviews and meticulous wording. Of course, introducing considerable changes in a project with this many stakeholders is no mean feat, but ten years in today’s tech world is a literal lifetime. Another challenge is that the ISO committee is predominantly Western, with a heavy underrepresentation of big Asian C++ users like India or China. These downsides don’t look good, especially not in the light of rapidly-growing, modern, openly governed (and relatively young) languages like Rust or Swift.

Is the technical debt of the C++ language really of such gargantuan proportions that it’s next to impossible to add new high-impact features? One-man army Sean Baxter of the Circle C++ compiler has shown that it’s not. In the past months alone, he single-handedly demonstrated that it’s possible to add considerable features like a true sum type and language-level tuples. Granted, an implementation in a single compiler of a C++ dialect without a thoroughly reviewed proposal is far from an official C++ language feature, but at least it shows how much wiggle room and opportunity there is in the syntax and language as a whole – if we really set our minds to it. It also shows that the burden of technical debt alone isn’t the limiting factor in the language development.

The C++ language governance model isn’t likely going to change anytime soon, being so tied in with the ISO process and the committee stakeholders. Still, I think right now is a very important time for C++ to consider its position in the systems programming universe; it can’t ignore the signals any longer. Perhaps a leaner governance structure will help, or allowing for breaking changes to shed technical debt in a future version – who knows. Unfortunately, such substantial changes to the process will most likely take years as well.

Wait and see

Will the drawbacks cause C++ to be eliminated anytime soon? No, definitely not. The sheer momentum of the existing code and user base is overwhelming. ‘Just’ switching to another language isn’t an option for everyone, not even for Google. For that to work out, true interoperability with C++ (not just C) is needed, which is where alternatives like Rust and Swift still fall short. Not for nothing is Google advertising C++ interoperability as a key feature of Carbon, allowing to step-by-step adopt the language from a large existing C++ code base.

At the moment, however, Carbon isn’t much more than a rough specification and announcement. We’ll have to wait and see if it can live up to the expectations. In the meantime, C++ will evolve as well, hopefully positively inspired by the possibilities of Circle and other languages in the field.

In the new 4-day training course “C++ fundamentals,” organized by High Tech Institute in the last two weeks of March, Kris van Rens introduces participants to the language basics and essential best practices.