Disclaimer: I'm one of the founders of Ferrous Systems.

Ferrocene as a compiler is not inherently more suitable for safety critical applications than stock rustc as distributed by the rust project. It is for all intents and purposes the rust projects compiler, with all the certification paperwork - that's quite a stack of paper if you include all of it, but it doesn't change any of the functionality.

However, on a support/organizational level, there are quite a few differences. We run our own CI for all of our supported targets which allows us to provide different QA levels than the rust project does or even could support.

We do provide higher levels of assurance on some targets compared to upstream. For example, the aarch64-unknown-none target is treated as "tier 2" by the Rust project, meaning they don't run any tests for it. Instead, Ferrocene treats it as fully supported, and we ensure all tests pass on it when we merge any change (contributing back fixes when something breaks).

We can also provide support for targets that are not in the rust projects tree, or even require legal paperwork for access to test hardware etc., to the point that we can provide binary only targets that cannot be made available via the rust project.

On a support level, we also provide support for existing rust version, to the point of long term support for certified versions (2 years by default, more or less infinite with a separate support contract).

There's also minor things that are interesting to organizations: Notification of known issues, signed installers, ...

All of these things do not change the compilers behavior, but can be quite essential for organizations with long term, safety critical projects.

Aaaaaah OK. So it's a bit more like a certified distribution. Sounds similar to how we handled FDA/CE certified versions of Open Source software.

Thanks for the clarification, it's very useful!

Is there a list with supported targets? Do you focus on ARM or are there other targets common in automotive, for example Power Architecture like the NXP MPC series?

Depends on what you mean with „supported“ - the qualification is at the moment for ARMv8-A bare metal (aarch64), see https://public-docs.ferrocene.dev/main/qualification/report/..., mostly because that‘s what our initial customer intends to use.

We have other targets on the roadmap and can implement/qualify targets on request, so if you‘re interested in a specific target, we‘d be happy to talk.

> What's the merits that allow the certification? Is it technical? Is it bureaucracy and "just" certifications?

What’s the technical difference between bureaucracy and technical merit in this context? Two compilers with equal source: (1) is rubber-stamped (audited or whatever by humans) while (2) is not.

This is based on rustc(1) so a priori I wouldn’t expect much technical difference (other than perhaps the Ferrocene fork lagging behind a bit).

You are correct, the technical differences are negligible for most intents and purposes.

However, the certification covers not only the source that was used to build, but rather the entire process to produce the binary for the source, that is our (Ferrous Systems) organization, our processes, the review process to ensure that requirements match the tests, the CI, the quality management, how we handle new issues (for example reporting to customers) … So even if you’d build the Ferrocene compiler from the available Ferrocene source, this would not give you a qualified compiler - because it’s not been built by our standards.

So to a large extend, the qualification does not produce better software, it „just“ documents that a certain quality baseline is fulfilled. But, as part of the qualification process we test the qualified targets to a higher standard than the rust project itself - the aarch64-unknown-none target is a tier 2 target for the rust project, it’s built as part of the compiler release but not tested. It‘s our qualification target so for us it’s tier 1. And indeed, we did discover issues as part of the certification effort, so ticking the boxes to fulfill that baseline did indeed improve the rust compiler. We wrote a little about the things that came out of the certification process in an earlier blog post: https://ferrous-systems.com/blog/how-ferrocene-improves-rust...

Well, I didn't want to dismiss or minimize the importance of bureaucracy and certification, as I myself have been involved in FDA and CE certification.

Thing is, not familiar with rust and that certification, I didn't know how much "based on rustc" means. So I didn't know of the certification was more like "legal process and support" or something like "formal verification" or the like.