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 personally know of teams using modern tooling and expansive cloud based CI/CD with safety critical systems and we are talking hundreds of developers. This is in C++ with MISRA standards and DO-178 too.
I don't think it's fair to say C++ is safe and reliable as is. The only way it could be made safe is with a restricted version of C++.
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?
We use C++ at my shop for Level A and of course we very much restrict it. But the restrictions are more due to reducing the scope of what you need to show for your compiler.
> 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.
And it never will be. In aviation we certify three things: aircraft, engines and propellers. Everything else is at best certifiable, i.e. can be integrated into a product to be certified assuming all deviations, restrictions, caveats etc are considered when doing so.
Also, tools follows DO-330 and are qualified. It's their output that should comply with DO-178.
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.