[jandrewrogers]

Most interesting parts of US government will buy and consume software written in C++ without qualification or reservation for the indefinite future. People are wishcasting, it isn’t a serious risk. New systems are being planned in C++ today and language choice isn’t even mentioned. Parts of government have a lot of experience with C++ in high reliability contexts.

There are many advanced systems in government written in C++ that would be impractical to deliver in any other language even if you were starting from scratch today. Extreme data intensity and throughput requirements are actually causing systems written in memory safe languages like Java to be replaced with C++ systems currently. Rust is often not a good fit for the software architectures required unless you are comfortable writing a lot of awkward unsafe code.

The government is pragmatic about programming languages, not ideological. They use both Rust and C++ in new systems but not for the same purpose, both have unique strengths in certain roles that ideologues are loathe to acknowledge. I use Rust and C++ the same way.

[oasisaimlessly]

> Rust is often not a good fit for the software architectures required unless you are comfortable writing a lot of awkward unsafe code.

If you have to write "a lot of awkward unsafe code" in Rust, you're doing something wrong. I use C++ rather than Rust, but any time I'm implementing any sort of non-trivial data structure or inter-thread communication, I encapsulate it in a "safe" interface that is impossible to misuse (at least in debug mode) and clearly deliniates the boundary at which e.g. a memory safety or data race audit would have to cover. In general, minimizing the volume and surface area of "unsafe" code is a generally useful heuristic in any systems language.

[jandrewrogers]

You are misunderstanding, there is no other way to write this code. Even in C++ you have to do a bit of awkward stuff to make the compiler do what you want. The main issue is that lifetimes and ownership do not and cannot follow the object model of the programming language, and both are intrinsically not fully observable at compile-time, being solely resolvable at runtime. Recent versions of C++ have started adding first-class support for object models with these properties so hopefully this will become easier.

The base case here is user-space virtual memory, which is de rigueur for high-scale data intensive applications. Objects not only don't have a fixed address over their lifetime even if you never (logically) move them, they often don't have an address at all, and when they next have an actual memory address it may materialize in another thread/process's address space. And hardware can own references to and operate on this memory outside the object model (e.g. DMA). The silicon doesn't respect the programming language's concept of an object because it doesn't know objects exist. You have to design non-trivial async scheduling and memory fix-up mechanics to make all of this reasonably transparent at the object level. It is actually a pretty elegant model, complex compiler negotiations notwithstanding.

And of course, the reason we put up with the implementation complexity is that there is a huge gap in scalability/performance between this and the alternatives. Same reason people use thread-per-core software architectures. It works around some fairly deep limitations in the silicon and OS.