You may be interested in Ferrocene[0], a version of the Rust toolchain that is vetted for critical systems like automobiles. It's offered by Ferrous Systems, the same people who help maintain Rust Analyzer (the de-facto LSP for Rust).

[0]: https://ferrocene.dev/en/

Note that what Ferrocene is currently offering is a toolchain. Things like core and std are not part of the current certification package. It's an incredibly exciting offering, but it's not quite ready to ship today. The fact that the certified toolchain is just the normal, publicly available one is great too.

> The fact that the certified toolchain is just the normal, publicly available one is great too.

And speaks to the standards of quality that the project holds itself to.

Yes, Ferrocene is able to be qualified more easily in part by how good upstream development practices are. A lot of qualified compilers need to be written from scratch because the existing compilers do not do testing and other things that are required for qualification, but the upstream Rust project has a development process far closer to a safety qualified compiler than not. It’s something worth celebrating about rust as a project.

> Things like core and std are not part of the current certification package

As with C++ I'm not sure this makes coherent sense because of the relationship between the language and some elements of the supporting libraries - with respect to `core` specifically, the Rust programming language requires some of core.

Suppose you write a for loop. In Rust that's just sugar, and it's de-sugared into a loop that uses IntoIterator::into_iter, Iterator::next, Option::Some and Option::None which are all from the core library.

Hence the warning. They're not separable, but it's what the current state of the offering is. If you ship core anything depending on core or std, the burden is on you to ensure those parts of your code are appropriately qualified until they can get the situation sorted.

Thank you for the reference! Will definitely look into this!

I was recently looking into things along these lines, and my understanding of Ferrocene is that it's just regular Rust with extra tests added. I'd love to know if that's accurate or not. If it is accurate, I've wondered why Rust doesn't just include those tests in the core build.

In my understanding, no additional tests, but some additional platform support.

The issue isn't more tests upstream, it’s more the chain of responsibility for guaranteeing that results are connected to the specification and all of the paperwork that’s required, and ensuring it is accurate.

I looked into MISRA specifically for my previous job and Rust effectively complies with most of it out of the box, and what's left is either inapplicable or not difficult to catch with further tooling.

> further tooling.

Just a heads up, Rust does have further tooling. I wish they were more widely used

Here are three of them

https://github.com/creusot-rs/creusot

https://viperproject.github.io/prusti-dev/user-guide/

https://model-checking.github.io/kani/

The ferrocene morph of the toplchian is ISO 26262 and ASIL-D, and as this blog post is about rust in the ECU of a production vehicle of a large manufacturer.

It seems like it already has support in the relevant safety critical standards, at least in the automotive space.

Different kind of standards. MISRA is a coding guidelines standard, ISO 26262 is a functional safety standard, it concerns the whole system, including processes and the tools used (here is where the certification from Ferrocene and HighTec step in). There is overlap, but they mostly do different things.

SAE has a coding standard in the works for Rust in safety critical systems.

https://standardsworks.sae.org/standards-committees/safer-ru...