A few years ago when C++11 was published, people saw that C++ might be becoming a different language and a wave of enthusiasm got hold of the C++ community. “C++ is back!” was an often read sentence in blogs and articles. With C++14 out and C++17 and several TS on the horizon, is C++ getting back even faster? Is it getting back at all?
Back in late 2012 there was a blog post by John Sonmez of simpleprogrammer.com titled “Why C++ Is Not ‘Back’“. There he essentially states that, while C++ is a great language, the new standard did not change the fact that C++ is a niche language for performance sensitive areas and low level programming close to hardware.
His arguments are that C++ is not coming “back”, because other languages are much better suited to manage the increasing complexity demanded by modern programs and that newer, simpler languages are better suited for the future than C++ with its complexity even increased by the additions made for the new standard.
A few weeks ago, there was a blog post “C++ in the modern world” by the team developing the static analyzer PVS Studio. I won’t go over the whole article here, but the punchline is basically that while C++ is alive and evolving, it won’t return to the glory of the (g)olden days before managed languages where a thing.
There is no going “back”
The notion of C++ coming back to where it was before the rise of languages like Java and C#, or even the comparison of C++ now and then has a serious flaw: It is an isolated view of only the languages, competing for popularity in a fixed surrounding.
In reality, that surrounding has been changing. Hardware evolved rapidly in the last decades, enabling the use of interpreted languages and JIT compilers in the first place. Back in the days of C++’s popularity it occupied the same performance and low level niche John was writing about. The difference is that the niche was all there was to computing.
With the new hardware we got a host of new applications of programming. The range of things that need to be programmed has increased dramatically, for example web development, mobile applications and the cloud.
These are problem domains that have not been there in the old days, so it’s only natural that C++ was not designed for them and other, newer languages occupy those niches today.
Languages are very different, and therefore are fit to occupy different niches. However, those niches are not discrete spots, and in between the extremes there is a room where different languages may compete for popularity.
They compete in terms of language usability. When there are several languages to choose from for a given problem, there are several key considerations to be made. Usually, there is no single best language, and tradeoffs have to be made.
Among the important points are speed of development and efficiency of execution. Speed of development is where other languages usually outperform C++, due to the simplifications made, like automated memory management, more available libraries and better support in the IDEs and other tools.
When sheer amount of hardware is not enough or not present, when it comes to memory or performance bottlenecks, we need the ability to go low level and do some fine tuning. And this is where C++ still shines, and where it can’t come back because it never had been gone.
While that performance and hardware niche is not really small, I think that C++ has some good chances to gain some ground in other domains. In the past and future C++ standards we have some good improvements in easier to write syntax and the amount of standard libraries.
There are additions that aim to make C++ fit for the many core age, and several working groups are working on support for features that have not been supported well in the past, for example networking, game development and real time applications.
When it comes to tooling, I think that there are some promising tools emerging. In the past years we got dependency managers like biicode, several static analyzers and other tools like ReSharper for C++, and who knows what tools the Clang community is going to roll out in the future. I would not be surprised if there already is an IDE in the making stuffed with lots of useful tools based on those libraries.
C++’s niche in the future
There is another issue that could be a good chance for C++ in the future: Hardware restrictions. The size of problems that need solving is ever increasing, so the programs written to solve those problems will demand more and more computational power.
More computational power means more chips or more powerful chips. The chips themselves might be a problem some day, but the even bigger problem already today is the electrical power needed to operate those chips.
The “C++ in the modern world” article states that mobile platforms are already occupied by managed languages and objective C. However, the time may come when resources on a mobile device are an issue and having a VM running in the background in addition to all the apps managing our lives is just too much.
The same goes for cloud computing where facilities are consuming unimaginable amounts of power to heat up server rooms with our programs and cool them down again with their air conditions. Another market is the Internet of Things, where more and more embedded devices will need a language that delivers good performance, close to the hardware.
The performance niche C++ is occupying is growing, and so will be the popularity of the language. Maybe, if WebAssembly becomes a hit, there might even be C++ based web applications in the future.
I can not say for sure if C++ is a language of the future of if there will be another to challenge its place. What I know is that C++ never was dead, and it won’t be for a long time. Neither will it just sit there in its niche, because it is evolving faster than ever as the computational world is changing.
However, I don’t expect adoption of the “new C++” to be as fast as with completely new technologies, because C++ has its history and there are lots of prejudices to overcome against a language that is conceived to be cumbersome and not simple enough. I disagree.