US Federal Government Effort to Champion Adoption of Memory Safe Languages

The National Cybersecurity Strategy from the Office of the National Cyber Director (ONCD) has established an Open-Source Software Security Initiative (OS3I) to champion the adoption of memory safe programming languages (e.g. Rust, Go, Julia) and open-source software security.

A recent Request for Information (RFI) aimed at furthering the work of OS3I by identifying areas most appropriate to focus government priorities, and addressing critical questions was made. More than 100 organizations and individual experts responded to the RFI. This included some DOE labs and a number of major commercial technology companies.

What does this mean for the future of C++?

Todd Gamblin, an expert on the HPC software ecosystem as well as a studious observer of trends in commercial industry had these remarks about it.

Commercial developers are shipping major products in these languages (Rust, Go, Julia to a lesser extent). The linux kernel is allowing contributions in Rust (and notably NOT in C++). Oxide computer just shipped an embedded OS written in Rust. crates.io has 130,000 packages. It’s a vibrant ecosystem, and people are choosing to do new projects in it over, most notably, C++. Go is real too. Kubernetes, Docker, and much of the cloud ecosystem is written in Go.

All that being said, the DOE HPC community just spent 7 years developing GPU computing capabilities — across 3 different GPU architectures. That represents a huge investment! And, we did that in, mostly, C++. It is worth noting that it was not the same old C++. It was C++11, 14, 17, and on. We’re talking about modern C++.

It is fair to say that the GPU ecosystem in Rust and Go is seriously lacking in comparison, and I don't think the investment in C++ was misplaced. The GPU ecosystem has a lot of momentum from AI and games -- that is a lot of inertia to overcome. Julia has some integration, being a very compute-focused language. It remains to be seen if the community will build HPC codes in it...or, if it is as viable for performance portability as C++ has been.

Whether the successor to C++, in scientific computing, if there is one, is going to be Julia, Rust, or Go is an open question. The answer depends strongly on what industry does and how well they can make fast, memory-safe alternatives to the algorithms and frameworks such as RAJA or Kokkos that DOE has built in C++. Notably, we have yet to see any major Rust or Go AI framework emerging. They are mainly Python + C++. There are attempts (like Mojo) to move the C++ parts to something more Python-like, and there are a number of projects moving to Python + Rust instead of Python + C/C++. py-cryptography, PyOxidizer, Maturin, ruff, and Pixi are some notable examples.

A final point to keep in mind is that most HPC applications are not (yet) services. They don’t need the same security guarantees that a library that sits listening for input on a port from random users need. That’s good and bad. It is good because they are unlikely to be attacked in the same ways. And, because supply chain security for HPC applications can set different priorities. It is bad because it weakens the case for encouraging anyone to move to a memory safe language merely for the sake of security.

Visitors to the RFI page will note about 100 comments are available there. In some cases, comments are just that...very short remarks from specific individuals. In most cases, an industry-leading organization has posted a lengthy response to the RFI as a PDF attachment. Among the 100+ responses, there were those in the table below worth noting.

Adding memory safety to C++ is a strategy to consider as well. See for example the Teuchos Memory Management classes developed by Ross Bartlet at Sandia more than 10 years ago. In addition, Bjarne Stroustrup, the creator of C++, spoke recently at Cppcon-23 about bringing Safety to C++. There is also a summary of his 1.5 hour presentation.