Re: It's not the language, it's just the way it's "talking"
>I do however like the idea that F-35s etc may in future be powered by Rust, if they're not already.
Not yet - Rust is too new. Parts of F-35 rely on INTEGRITY - the OS from Greenhills, and that's written in C (using Greenhill's own C/C++ compiler and C/C++ runtime libraries). If you want compilers, libraries and an OS that has strong assurances of being correct - look no further.
But it does smell like the US Gov (which will include the DoD) will start getting quite insistant on Rust being used, and I can see why.
What Else?
Rust is one component of it. Adopt it, forbid the "unsafe" keyword, and in theory you end up with code far less prone to memory mis-use errors.
However, when one looks at today's hardware, MELTDOWN / SPECTRE and similar are all about memory misuse / mishandling within CPUs. And it's interesting to consider what can be done about that. There have been articles here on El Reg on the topic of the need to get rid of C in the hardware sense too. C / C++ and today's libraries for them all assume that its running on a Symmetric Multi Processing hardware environment (for multicore hardware). But, the hardware hasn't actually looked like that for decades; SMP is a synthetic hardware environment built on top of things like QPI, or HyperTransport (or newer equivalents), and these cache-coherency networks are what is causing MELTDOWN / SPECTRE faults which the CPU designers are seemingly powerless to fix. Apple's own silicon has recently been found to have such faults - they're unfixable in M1, M2, and they've not disabled the miscreant feature in M3 even though they can.
So, it looks like we should be getting rid of SMP. That would leave us with - NUMA.
We've had such systems before - Transputers are one such example. The Cell processor in PS3 was a bit NUMAry also (in how one used the SPEs). Super Computer clusters are like this too (no direct addressability of data held on another node). Various researchers are getting re-enthused about such architectures, pointing out that even 7 year old kids can be taught how to program for them.
Of course, such a hardware switch devastates existing SMP-centric code bases, like Linux.
What Does This Have to do with Rust? I hear you ask? Well, Rust has (in theory) perfect knowledge of what owns what data and when. You pass ownership of a piece of data from one thread to another, and it knows you've done this. An object cannot be mutable in two places at once in Rust. It is almost completely ideal for conversion from running on an SMP environment to running on a purely NUMA environment. Whereas passing ownership at present is simply used to determine what code can use some memory, it could also serve to prod the runtime that data needs to be moved from from NUMA node to another.
In otherwords, Rust is a pretty good candidate as a language that suits both SMP and NUMA architectures.
Golang is another - in fact, Golang makes no bones about being a recreation of the the Transputer's CSP architecture. GoLang is quite hilarious / ironic in the sense that it implements CSP, and has to do so in an faked SMP hardware environment, where most of today's hardware has more in common with the Transputers that with actual SMP hardware of the 1980s / 1990s.
Python multiprocessing is another. Copy data from process to process - don't share it.
This then opens up the possibility that the US Gov - having "forced" Rust on to the software world, got a Rust OS - might then start requiring hardware architectures to drop SMP too.
The Future
That hardware shift is some way off, and a bit of a long shot. However, if it does come, persisting with C / C++ code bases for whatever reason could become an even bigger liability in the future than anyone is thinking of at the moment. Not only might it become hard to find developers willing to write in it, or customers willing to accept code written in it, it may become difficult to find hardware to run it on.
That ought to worry the likes of Linux more than it appears to be doing so.
To be certain that today's SMP environments will survive and will be able to keep running C/C++, these projects need the hardware manufacturers to fix cache coherency / hardware memory faults for once and for all. Though there seems little prospect of that.
Shared Memory is, Today, no Different to Copied Memory
The classic "don't copy data, send a pointer to data if you want it to be fast" is maxim that should have died decades ago. It was only ever true in actual SMP environments like Intel's NetBurst of the 1990s.
Today, for one core to access data in memory attached to a different core, pretty much the same microelectronic transactions have to take place as would be required to simply copy the data. If code on Core 0 accesses an address actually in memory attached to Core 1, then a copy of that data somehow has to find its way into Core 0's L1 cache before the code can actually do anything with it. But, that is a copy. The problem today is that it's a copy that - because this is an SMP environment and Core 1 has also (probably) accessed that address recently, there has to be a lot of transaction between the Core 0 memory subsystem and Core 1's, to make sure that all the caches everywhere all have the current content of that address.
If you look at any Intel CPU today, you may end up with copies of the data in CPU0 / Core0's L1 and L2 caches, and in CPU1 / Core2's L1 and L2 caches, and probably also in one of the L3 caches somewhere as well as in some DDR5 memory chips. That's six copies of the data, all of which need to be kept in sync with each other.
Just think how much easier the hardware would be, if such sharing were entirely up to the software to resolve, and how sweet that'd be if it was all resolved because the programming language's syntax made it very clear where the data needed to physically be?
That's how important Rust could end up being, giving us a bridge from yesteryear's outdated and difficult hardware architectures to tomorrow's.
Biting the hand that feeds IT
