In the weeks since the announcement of Carbon at CPP North there has been some buzz around the future of C++. There is certainly a question for debate how a language that is still very much in its early infancy could generate such buzz. There is also a question of how it compares to other claimants to the crown like Rust.
When speaking about the future of C++, we need to remember that predictions are hard, especially about the future (we already used this quote in another blog post discussing the evolution of C++). Let’s take the risk and try to predict some trends.
A Language in a Midlife Crisis
In his closing keynote at CPP North, Sean Parent discussed the challenges of C++. The talk, aptly titled “The Tragedy of C++, Acts One & Two”, dove into the factors that made C++ succeed and why these exact factors might be its downfall. After the talk, to further expound on the title of the lecture, Sean posted in his site the following:
“What makes a tragedy a tragedy? It requires the protagonist to be successful, or the story is simply tragic and not a tragedy. C++ is successful. In Act One, we explored the reasons why C++ is successful in introducing our character. In Act Two, we looked at how some of the very strengths of C++ can also be very damaging.”
So what exactly are these strengths-turned-weakness? Sean starts with the standard, which is a significant factor for C++ success, bringing very clear and stable definitions for both compiler vendors and developers. But the standards have become lengthier and more complex over the years (from 757 Pages in C++98 to 1807 Pages in C++20). Timur Doumler has already covered this issue in his talk on C++20 at CppCon.
He then continued with the complexity of the language itself, demonstrating it with std::pair that grew from 62 lines in C++98 (SGI) to 372 lines in C++11 and up to 502 lines in C++20. Would you say a language that requires 502 lines of code to express a pair is efficient? And yes, there are good reasons for that – it’s a piece of generic programming code. But there are too many examples in C++ of low code density and too many lines of code trying to express a small thing (that might be better expressed in other languages). A good example that I can think of is C++ lambdas. A proposal for abbreviated lambdas was rejected, perhaps for valid reasons – but the result is that C++ lambda code is more cumbersome compared to other languages. Another example is variadic pack expansion, with std::integer_sequence or other convoluted techniques, instead of a simple index syntax (implemented in Circle).
The set of complex features C++ provides make it the only software language that can have real development questions like this one in StackOverflow, titled “Is it possible with C++20 to have a constexpr function return a tuple of types that have static constexpr arrays with a value passed through a macro?”. On the other hand, it is not that everybody thinks C++ is complicated. See for example this reddit post: Started learning C++14 heavily and I feel like I’ve been misled by the harsh comments like “C++ is a horrible language.” Yes, it is more complicated than many other languages, but is that so bad?
Another aspect Sean’s talk discussed was the low-level tools that C++ provides, which eventually may hurt performance. When you describe what you want to achieve in a high-level declarative way, the compiler or the environment may be able to better optimize your use case compared to low-level code which may seem to be more efficient. C++ gives you the ability to use low-level tools, but Sean’s argument is that in many cases these tools would hurt you, e.g. by creating too many threads, eliminating options for SIMD vectorization or other optimizations. Additionally, there is a growing need for GPGPU (General Purpose GPU) computation, preferably without the need for external libraries. As Sean explained:
“Without addressing vectorization, GPGPU, and scalable parallelism, standard C++ is just a scripting system to get to the other 99% of the machine through other languages and libraries. Do we need such a complex scripting system?”
And while Sean said he does not see any quick path for fixing C++ issues, it is not that we can abandon our C++ codebase.
So, the challenges for C++ are clear. It is not becoming any easier over the years, as it needs to carry its legacy burden. (Yes, you can focus on a subset of the syntax and ignore old ways of doing things. But it is still not the same as a brand new, clean and concise language). The spec is getting bigger and more complex. And it doesn’t solve some of the problems we would expect it to solve, such as better declarative high level programming for multithreading, vectorization and GPGPU.
Some see the ISO committee process of C++ as an obstacle for change. It might be that a democratic and open process for a language is a bad thing – there are too many views, it’s hard to get consensus to move things forward, and it encourages compromise instead of clear single conceptual integrity. This may serve as a catalyst for new languages that do not have to follow such a process, or can create their own process (such as an open process without the need to reach consensus or a more centralized process).
In the end, though C++ is still very popular and far from being retired, with conferences around the world, hundreds of blog posts and an enthusiastic community of developers. Software languages are not here forever. They lose their position if something better comes up, as new projects move to better alternatives. It is not unlikely that C++ could be less in use and less popular a decade from now.
Source: Twitter
In part two, we will discuss the alternatives for C++, what they are aiming to solve and some more concrete thoughts on the future of C++ with its alternatives in mind.
