For some time, C++ has seemingly faced a slow decline in popularity. It is now ranked between sixth and ninth places in the most recent GitHub Octoverse and StackOverflow’s developer survey, respectively. However, there are many prominent C++ applications still in use: for example Windows, various databases, PhotoShop, MS Office, and Chrome are some of the better known. Clearly, it is not going to vanish overnight.
But let’s say we’re at the beginning of the end of C++. Here are some indicators that the language could continue losing ground:
Memory Issues
In February this year, the White House published a 15 page Technical report (PDF) which calls for a shift to memory-safe languages. Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++.
C++ is one of languages that lacks automatic garbage collection. Avoiding memory leaks needs careful programming; when memory leaks occur in non-trivial programs, it usually requires third-party tools such as valgrind to detect them.
As long ago as 2013, the IEEE published a paper on memory corruption bugs in C/C++ software: Memory corruption bugs are one of the oldest problems in computer security. Applications written in low-level languages like C or C++ are prone to these kinds of bugs.
The Rise of Rust
The increase in Rust use by developers such as Microsoft, Amazon and Google is another bell tolling for C++. Last year, Microsoft started rewriting parts of the Windows kernel in Rust and mandated that new software projects should use Rust rather than C/C++. They now provide instructions for getting started for writing applications in Rust on Windows, as well as crates (packages in Rust) for calling Windows APIs in Rust.
The Natural Evolution of Programming
There are two schools of thought about the future of C++. One school wants to make changes to the standard libraries; for instance, adding default arguments to functions, adding virtual functions and making tweaks to string, vector and other container layouts. These are all things that would break the ABI (application binary interface).
The second school wants no changes to the ABI to ‘maintain stability.’ However, not breaking the ABI could cause performance losses on the order of 5-10 percent (a long read explains it in more detail).
Earlier this year in Prague, one committee overseeing the future of C++ decided to vote in favour of not breaking the ABI. The preference seems to be backward compatibility. But will stability impact the growth and sustainability of C++?
Considering Carbon
Google uses a lot of C++ and has concerns about its future. Enter Carbon, an experimental successor language to C++ that was started in 2022. From reading the Carbon documentation, there seems to have been some considerable frustration with the direction of C++.
While Carbon isn’t replacing C++ (as that would be a massive task), it could augment C++ by letting you rewrite some C++ code in Carbon. TypeScript is an example of a similar superset of JavaScript (i.e., it transpiles code into JavaScript) that became immensely popular; it’s not out of the question that Carbon could do something similar to C++’s market share.
Meanwhile, Kotlin and Java is another example of an older language (Java) being eclipsed by a newer one (Kotlin) for the same function. Google’s Android was a Java-centric platform, but now 60 percent of developers working on Android apps and features rely on Kotlin.
Why might you use Carbon?
As said earlier, it’s the safety aspects of C++ that are a cause for concern. Carbon has an interesting approach to implementing memory safety via its use of build modes. In debug build mode, the code has safety checks built in; performance build mode prioritizes performance over safety; and hardened build mode produces release focused binaries that are strengthened for safety rather than performance.
Carbon doesn’t inherit the legacy of C or C++ directly. But it’s starting with solid foundations, such as a modern generics system, modular code organization, and consistent, simple syntax. The Carbon roadmap suggests it’s not going to be completed for several years, perhaps reaching version 1.0 sometime after 2027. However, if you program in C++, it’s critical to pay attention to everything Carbon-related.
Conclusion
Carbon is clearly an alternative to Rust and spares C++ developers the expense of switching completely to Rust (which would be a significant cost, particularly for massive projects). But it’s still early days for Carbon; there’s a lot to do. You can track progress of the main Carbon repository on GitHub.
