Another one bites the dust
Some reflections on why a language specification for Rust is a significant step for using it in safety-related contexts in the next few years.

The announcement that Rust will receive a donor specification from the team behind Ferrocene was welcome news to me this week. It did have me reflecting on the importance of this and also hopefully a bit of a teachable moment to blog about!
Generally speaking, languages that are deemed 'appropriate' for safety-related systems can be said to have some mixture of the below characteristics:
- The language's behaviour is well-defined, and any ill-defined behaviours are highlighted as such so these can be avoided.
- We see this with languages such as Ada and C++ where there is an international standard defining the language, its behaviours, etc.
- Having a formal, written language specification enables technologies such as compliance testing suites, which put a compiler through a battery of standardised tests, developed to exercise the full language specification.
- The language possesses desirable safety properties.
- Each language approaches this differently: some languages bake this into the language directly while others can be made to have the required properties through use of coding standards and other methods.
- The language has a suitable ecosystem of tooling around it which enables the various requirements of functional safety standards to be addressed.
- In most cases, this is about ensuring that the language is amenable to both dynamic and static analysis of varying degrees, as this is fundamental to pretty much all mainstream functional safety standards.
- The language is perceived as appropriate for use in safety-related systems.
- This one is probably the hardest criteria to actually define, at least in my estimation.
- Generally this point is about having had industrial-grade application of the language to real problems and provable success.
- It also suggests an implied stability in the language over a longer period of time, so frequent re-work of significant language features can be seen to reset the clock on this criteria.
Rust, to me and I'm sure many others, has always been fantastic on the second criterion given its emphasis on memory safety, borrow checking, etc. The adoption of a formal language specification by the Rust Foundation goes a significant way to addressing the first criterion.
Of the remaining barriers, I'm aware of significant effort going into producing industrial-grade tooling for static & dynamic analysis from the usual major vendors, so 3 of the 4 criteria are probably achievable in the near future.
This just leaves the perception of whether Rust is suitable as a 'safety' language, and unfortunately, this is a much harder thing to put estimates around. That being said, I remain upbeat about the prospect of being able to utilise Rust successfully in safety-related programmes by the end of the decade.