People need to ask themselves what benefits Rust would bring to an high assurance system (e.g. DO-178C Level A). You're not gonna want to malloc mid-flight even if you have a borrow checker.
The entire point of e.g. DO-178C is to show that the software only does exactly what it is supposed to do under all assumptions and have any derived behavior fed back to the safety process for evaluation. Software can never in itself make a system safe.
All that aside, modern tooling may be more ergonomic etc so I'm not saying languages like Rust shouldn't be considered, they just aren't as useful here as I think a lot of people assume.
I'm reminded by mozilla's sign "You must be this tall to write threaded code." [1] How much do you restrict your language and libraries to make it safe? Like custom templates? How do you define ownership of objects and lifetimes -- or just malloc everything all at once?
[1] https://bholley.net/blog/2015/must-be-this-tall-to-write-mul...
> or just malloc everything all at once?
Yes! But here's the thing: this isn't done due to the footguns associated with memory management, it is done because you want as little dynamic behavior as possible. For Level A software you need to show that your software has both bounded execution time and memory usage, and be robust against all inputs. Achieving that is so much easier without dynamic memory management.
Also, another thing to keep in mind is that DO-178 has you show that your software requirements are traceable to system requirements, your software design to your software requirements, your source code to your software design and your object code to your source code. But testing should be requirements based. So if your compiler inserts a bounds check now you have object code not traceable to source code and for which you won't have coverage because your requirement mention it. But what if you mention it in your requirements? Well, then you'd have to implement it manually in source code to uphold traceability anyway...
I will caveat the above by saying that other players may interpret things differently or have found ways to do things more cleverly.
Ferrocene isn’t DO-178C certified… yet. But it has similar certifications in other industries.
Also, tools follows DO-330 and are qualified. It's their output that should comply with DO-178.