There's a number of reasons. Anything in a regulated industry like that has to have everything approved by regulators. The whole compiler toolchain, all libraries, blah blah. All have to be certified versions before you can use them. You can't just pick up github latest compiler and expect to ship a safety critical device with it. Coders in regulated industries may have never even heard of github, much less rust. Different mindset.
Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS.
Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others.
Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require.
Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar?
None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.
Rust’s ownership model isn’t useful just for heap-allocated things; it’s useful for all kinds of other safety guarantees, such as preventing unnecessary mutability.
To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.
Nice. Is it frequently used in contexts outside of allocation? I assume allocation is the primary use, or at least it's the most talked about, but I have never done anything complex in rust.
One example of where it's used: to enforce correct usage of mutexes. Rust's `Mutex<T>` owns the data it protects. When you lock the Mutex, you get a reference to the data inside it, but it's impossible (a compile-time error) to store a copy of the reference beyond the point where you release the lock.
Cool. So the fifth point is largely nullified, which is a big one -- that the features of Rust would at least be useful in typical safety-critical code.
The most common AFAIK would be when using iterators. An iterator borrows (or mutably borrows, or takes ownership of, depending on how it's called; iter() vs iter_mut() vs into_iter()) the original collection, so the original collection can't be modified while being iterated. This means no "ConcurrentModificationException" or similar (or worse, silent corruption) can happen.
"Linear type systems are the internal language of closed symmetric monoidal categories, much in the same way that simply typed lambda calculus is the language of Cartesian closed categories. More precisely, one may construct functors between the category of linear type systems and the category of closed symmetric monoidal categories." (Wikipedia)
So now the only question is where closed symmetric monoidal categories are applicable :P
Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS.
Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others.
Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require.
Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar?
None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.