In the next 10 years I expect C++ modules to become more accessible. Most C++ vendors have at least some support and CMake recently announced its feature set. However, transitioning existing code bases and, in many instances, bespoke build systems will be a great obstacle.

In the C++ feature department, we can expect static reflection, pattern matching, contracts, and sender/receiver to become available over the next decade.

AI-assisted coding is following the well-trodden Gartner hype cycle where inflated expectations precede an ultimate plateau of productivity. While we’re thankfully past the idea that AI-backed productivity gains will result in massive Software Engineering workforce reductions, I don’t think it is yet clear to what extent AI will improve software development productivity.

Another major factor over the next 10 years will be the growing usage of Rust by C++ developers.

One might wonder if today’s C++ successor hopefuls — Hylo, Swift, Cpp2, Carbon, Zig, Mojo, and Rust — will gain more traction at this time.

Swift and Rust are likely to remain due to the world’s existing dependence on them.

C++ will remain important in niches, companies with large existing C++ code bases, and surrounding software assets no one wants to rewrite.

In the 10–20 year timeframe a few industry shifts will start to take hold. First, memory safety legislation will make usage of C and C++ for new projects require special justification and oversight. Safety-critical applications will see C++ entirely phased out.

Second, software engineering as an engineering discipline will mature with regulatory oversight, inspections, and enforcement of best practices becoming commonplace.

Finally, on the application side, AI will become the dominant form of human-computer interaction.

C++ in 20 to 30 years: This period is difficult to predict, but the world will likely remain highly dependent on complicated and memory-unsafe C++.

However, rather than people, AI will be doing most of the coding; it will find and fix defects and we’ll trust it to do so.

“While formal methods have been studied for decades, their deployment remains limited; further innovation in approaches to make formal methods widely accessible is vital to accelerate their broad adoption.” — White House

Well gosh. I applied to US research programs with an interest in formal methods and was rejected absolutely across the board. Good luck to you. ↑

“I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,” Stroustrup said. “On the other hand, they seem to have realized that a programming language is just one part of a tool chain, so that improved tools and development processes are essential.”

Biden administration seems oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees, Bjarne Stroustrup said.

I’ve been in the industry long enough to know that there’s a significant number of devs that will refuse to adopt new language standards. I’m 100% confident there are C++ devs still writing C++03 style code. Both because they simply haven’t taken the time to know what’s in C++11 and later and because they have some mistrust and even irrational fears about enabling C++11 and later feature sets on their codebases. ↑

I really respect Bjarne Stroustrup, but (oh boy here we go) he seems to not understand the fact that the problem is not in the language but in programmers who are failing to keep up with the pace of learning the safety features of C++. ↑ Huh that’s actually fair

Non-memory safe languages include C and C++, both of which are commonly used today. Memory safe languages include Rust, Go, C#, Java, Swift, Python, and JavaScript

Your operating system does not offer memory-safe APIs. To do anything useful, you must call into the operating system. This means every program would be infected via this conception of safety, and therefore, as a definition, it would be useless.

If we instead make an exception for a language’s runtime, which is allowed to make unsafe calls, but users’ code is not, that would draw an appropriate boundary: only write code in the guest language, and you don’t have to worry about safety anymore.

Putting the focus on memory safety is more than a little suspect when the worst CVEs come from programmers not putting in basic checks for path traversal and forgetting to fully check user credentials. What is also worrying is the complete lack of any reference to the favorite language of the military, medical, and aviation fields where things going boom (prematurely) is generally considered a bad thing: Ada.

Even so, Ada’s lack of popularity outside of the aforementioned fields has led to a dearth of Ada programmers, which has resulted in C++ ultimately being approved for DoD projects like the F-35 program, albeit with strong restrictions on acceptable code to bring it more into line with Ada. What this shows is perhaps that the problem is not so much C++, but more how you use it.

After all, C++ by itself has no major issues with memory management or a lot of undefined behavior as long as you keep away from its C compatibility syntax. With RAII (resource allocation is initialization) and encapsulating code into classes with well-tested constructors and destructors, you avoid many of the issues that plague C. Add to this C++’s standard template library (STL) with std::string and containers that replace the nightmarish and error-prone C-style strings and arrays, and suddenly you have to try pretty hard to get code that has any memory-related issues, because simple buffer overruns no longer happen.

Perhaps in this era of instant-gratification LLM code generating tools and “cut/paste from Stack Overflow”, we have forgotten the most important thing of all about programming. Namely that it is an engineering discipline that requires planning, documenting, testing, and feeling like the more you learn, the less you know, and the more easy mistakes you make as you write more complicated programs.

This is perhaps why the ONCD report feels so wrong, as it contains none of the lessons of the past, nor the hard-won experiences of those who write the code that keeps much of society up and running. You can almost hear the cries of many senior software engineers as they wonder whether they’re merely chopped liver in the eyes of government organizations, even as said organizations are kept running due to countless lines of Ada, COBOL, C and C++ code. Never mind the security researchers who despair as basic input validation is once again ignored in favor of buzzwords pushed by a couple large corporations.

It’s unfortunate that mr. Sutter still throws C and C++ into one bucket, and then concludes that bounds checking is a problem that "we" have. This data really needs to be split into three categories: C, C++ as written by people that will never progress beyond C++ 98, and C++ as written by people that use modern tools to begin with. The first two groups should be considered as being outside the target audience for any kind of safety initiative. ↑

The online discourse quickly devolved into “just rewrite it in Rust bro!” which I find a bit unfortunate because it is a relevant report and the use of memory safe languages is just the main recommendation, other possibilities are given. I urge everyone to actually read the report and not just immediately jump to conclusions.

C++ has too much undefined behaviour to become a safe programming language in the foreseeable future. One way or another, all the C++ experts cited here agree on that.

<…​> the narrative of C++ as inherently unsafe oversimplifies the situation. The language has undergone substantial evolution, with modern iterations emphasizing safer memory practices without compromising the language’s core principles of efficiency and control.

The journey toward making C++ a safer language is complex and fraught with challenges. However, the discussions and proposals led by Stroustrup and supported by the broader C++ community suggest a forward path that respects the language’s legacy while addressing the pressing needs of modern computing.

Right now, many of the articles about modern C++ and memory safe C++ end up preaching to the choir. The advice doesn’t reach all corners of industry, and many places in academia are stuck in their ways. If you go to small CS programs at small schools, you will frequently find people learning C++ as C++ 98 or C++ 03, so they see C++ as “C with Classes and Templates” or “Java without a GC”. ↑

"Why do you have a messy pile of clothes in the chair?"

"It’s L1 cache for fast random access to our frequently used clother in O(1) time"

"Embedded software development" is when you write software in your bed