A Decade of Rust, and Announcing Ferrocene
ferrous-systems.com
ferrous-systems.com
Does this mean they're going to have a curated subset of crates they'll be willing to vouch for? Cool if true, but sounds like a very significant amount of work.
Not coincidentally, it's the sort of work that the sort of people who use verified compilers have the incentive to pay for.
This link contains more information.
I guess some sectors care about having a compiler that conforms to some sort of ISO standards. This doesn't really tell me what that means but I know that I'm not the target.
Essentially, the ISO 26262 certification mostly verifies that the compiler release process conforms to a certain standard. It does not create an ISO standard for rust, not does it aim to. At part of the certification process we had to write a spec for the rust language, but it is a descriptive spec of how certain aspects of the rust language behave for one specific release of the compiler.
The certification builds on this to ensure that tests catch deviations between spec and implementation, known problems are documented etc. So rust as a language is unaffected, as is the rust project. The spec is open source and might be useful to others, you can find it at https://spec.ferrocene.dev/
The target sectors for ISO 26262 and related industrial certification are clearly sectors that require such certification: automotive, medical, etc.
Ferrocene itself however, is not only the ISO certified downstream of the rust compiler, it also offers for example long term support and tracking of known issues which the rust project does not provide. This is also important for certain applications that do not strictly require certifications.
Disclosure: I'm one of the founders of Ferrous Systems, but I'm only involved in the Ferrocene project on a moderately high level, so forgive minor technical inaccuracies :)
Sorry for a stupid question, but what does this mean?
Is it only that Rust itself (the language) is no use in a certification, but rather a specific compiler version? I.e. basically leading to the same outcome in the end.
Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?
"certification" is something that is done to a process that produces a software artifact.
So yes, in some sense it is "particular compiler version." The result of certification says "this compiler will do this when given this, and here is how we ensure that that is true, and here's the process for when that's not true, etc etc etc." Users can then use that specific compiler.
> I.e. basically leading to the same outcome in the end.
The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way. It does require that a specific inputs to the compiler are described, and because compatibility with upstream Rust is desired, those specific inputs happen to map to inputs to rustc that are identical, but it is important to understand that this can happen completely independently of what the Rust Project decides is best for the language; this is a downstream project.
In theory, if the Rust project wanted a specification, starting with some of the work Ferrocene has done would be an option. But the qualification process doesn't require that.
> Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?
The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.
> The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way.
Sorry, I was being vague. I meant the outcome for "us", the users, creating certified software relying on Ferrocene.
Totally on board with that there is a huge difference for certifying Ferrocene itself.
> The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.
Nice, that's what I was hoping for. We are currently in a project creating safety certified software (in C, as are our other code) and are curiously looking at Rust, partly because of this effort.
The main page for Ferrocene says "ISO 26262 and IEC 61508 qualified" with "DO-178C, ISO 21434, and IEC 62278 in the future," so depending on exactly which things you need, Ferrocene may work, but it also may not.
Note that it doesn't have to be a separate version with patches - it may as well be a recent stable release of Rust. But the paperwork has to be created just fro this release. And these standards require a team to spend months and months documenting everything. That's why having it all done by a vendor like Ferrous Systems is attractive: once the work is done adapting it to some other "compiler version + hardware" combination will take a lot less time.
There was an audio interview where Ferrous people talked about it https://rustacean-station.org/episode/067-quentin-ochem-flor...
It essentially is, we're pretty open about this. There's a tiny patchset that's required to enable some guarantees (literally a handful of patches), none of them of interest to the upstream project. Every major change has been contributed upstream. Even the spec that was built as part of the effort is open source.
Do you perhaps have a link where we could see those patches? Purely for curiosity's sake.
I've been doing more Rust hacking at home and I genuinely think that this next decade will be just gangbusters for Rust; its gotten a lot of early adoption, and the next wave is going to be wild.
one of these days I'll work at a Rust shop, and I am hyped for that possibility. it'll be NICE.
That said, Matician's vision mapping looks really cool.
Ecological it's quite interesting: Currently people run inefficient appliances which are decades old till they fall apart and the appliance can't be recycled.
If we would transition to a model where they are rented "all inclusive" the vendor might have a very different motivation to make sure people got a modern device and it's built in a way that as many parts as possible can be reused.
75/month seems high for vacuum though.
Microsoft is rewriting their core kernel parts in Rust.
Asahi Linux drivers are written in Rust.
All new critical performance stuff in Cloudflare is written in Rust.
List goes on…
Edit: Many instead of all new from Cloudflare..
That's an exaggeration. Yes, we use Rust a lot and in performance critical areas but it's definitely not "all new critical performance stuff".
Think of `workerd` as the "kernel" of our "cloud operating system". We try to avoid putting things in the kernel if we can. Features like Workers KV, R2, Queues, D1, etc. are generally built as "userspace" services, that is, they run as Workers.
Durable Objects is a bit special, it's inherently something that needs to be in the core runtime, and which many of these other services build on top of.
FWIW, if I were starting over I'd probably write the runtime in Rust, but it wasn't quite ready yet when we started six years ago.
(I'm the tech lead for Workers.)
mmmm... the Windows kernel? Amazon Firecracker (the AWS Lambda engine, afaik)?
I have used Rust off and on for a decade, and in the last 5 years Rust has really moved from hobbyist to making inroads at big tech firms. It is good to be skeptical though. Language boosters can be annoying. :)
For rust to succeed in those spaces a "community compiler" is just simply not an option. Having a standardized language (which is still not there yet) with a qualified compiler toolchain would be a significant step forward and actually makes it perspectively possible to use rust on projects for commercial aviation.
A compiler not complying with the standard is also not that problematic, as long as the deviation is known. UB should be avoided under all circumstances, but it is inherent to any language as spread out as C.
Because we're talking standards, precise wording is important. You do not need a standardized language in order to produce a qualified compiler.
> I don't think having rustc as the "defacto" standard is in any way acceptable to use it on an airplane.
This is true but not because it's a "defacto standard," it is because rustc does not fulfill the requirements to be qualified. Ferrocene, on the other hand, does.
> A compiler not complying with the standard is also not that problematic, as long as the deviation is known.
You're correct here, but that's directly in conflict with the "you need a standardized language," which is why I'd disagree with that portion of what you've said here.
The Ferrocene guy mentioned that they worked on some formalization of rust, probably because tracability without it seems sonewhat impossible and maybe that is already enough for the FAA/EASA.
But you said it yourself: deviation from a standard is fine. There is no requirement that there is some sort of upstream standard that must be adhered to.
If the language has no standard, like rust, you have to essentially create a standard. Afaik rust has no documentation which satisfies those requirements in any way.
> Afaik rust has no documentation which satisfies those requirements in any way.
That is correct, Rust does not. Ferrocene does. And that's perfectly fine according to the requirements.
Is there FAA/EASA certified rust SW on a commercial airplane above DAL E? If not ferrocene potentially does.
>For a programming language, it must have an ISO standard
Which is also not what I am saying. It is obviously not important that it is an ISO standard (the DO certainly has no such Requirement), but you need some documentation which specifies the language. For C/C++ that is trivial, as it is standardized, for rust it isn't.
I fully agree that you can conform to the DO by having a company like Ferrocene which provides that documentation. And that has a compiler toolchain which states how it complies with the specification. And I am glad that they are doing this, as this is a step in the right direction.
> Is there FAA/EASA certified rust SW on a commercial airplane above DAL E?
So, I don't work in the industry, so I am not 100% sure. What I do know is this: https://www.lynx.com/press-releases/rust-compiler-support
> Lynx Software Technologies (Lynx) the leader in delivering solutions for the Mission Critical Edge, today announced that its LynxOS-178 operating system and LynxElement unikernel will include support for Rust... LynxOS-178 is a native POSIX, hard real-time partitioning operating system developed and certified to FAA DO-178C DAL A safety standards.
So the interest is there, at least, but given that Ferrocene is currently only qualified for ISO 26262 and IEC 61508, with DO-178C, ISO 21434, and IEC 62278 being listed as "in the future," I am guessing that's something desired, but not true yet.
> If not ferrocene potentially does.
Yes, to be clear I meant conceptually, in a way that the Rust Project does not, and I would be willing to bet money that it never will. Not that it has passed that bar presently.