Rustacean Station had a great podcast episode with Quentin Ochem from AdaCore and Florian Gilcher from Ferrous Systems. They do a great job explaining what "safety-critical" means and the work that goes into validating software for such applications. I work in a slightly-less regulated field (medical devices) and found the discussion really interesting.<p><a href="https://rustacean-station.org/episode/067-quentin-ochem-florian-gilcher/" rel="nofollow">https://rustacean-station.org/episode/067-quentin-ochem-flor...</a>
Ferrocene is an exciting opportunity for the safety critical space which is dominated by MISRA C, Ada / SPARK, and similar.<p>Having AdaCore as a collaborator gives me great hope that Ferrocene will succeed and raise the bar for Rust standardization and language maturity.
one thing I don't fully get-<p>this specification is written based on the current behavior of rustc. The page even says that the specification will be updated as rustc is updated:<p>> If there is a mismatch between what the FLS says and how the compiler behaves, the specification will be updated.<p>So, rustc is not written to this specification, but rather this specification is written to match rustc.<p>So if I am writing my own compiler, using this specification, do I have to worry about the specification changing, if suddenly a regression is introduced to rustc, and the specification is updated to cover the regression?<p>mostly I don't understand. I'm sure someone could explain this and it will make sense to me.
I'd just like to see the tooling and compilers improve for Ada. Alire is fantastic, but It's still a huge struggle to import C headers (gcc -fdump-ada-spec is the best thing so far) and find the required linker flags for a library.
> One of the requirements for qualifying such a toolchain is to describe how the compiler should behave when compiling source code, which means a specification of the programming language.<p>Doesn't the reference implementation of the compiler already qualify as such a specification?
I'm personally pretty excited to see where this goes. It could be the best way for gccrs to version itself. There are some immediate aspects I am pretty interested in relation to the spec:<p>1. Method resolution<p>2. Unstable?<p>In particular is it going to define lang items?<p>3. DST's<p>Rust has strange things like:<p>```<p>let a:&str = "str";<p>let b:&str = &"str";<p>```<p>Which is valid since str is a DST. Although slices and dyn trait are DST they have more strict rules there.<p>4. Qualified paths<p>There are more subtle things like qualified paths such as this testcase which could be argued is valid <a href="https://github.com/rust-lang/rust/blob/master/src/test/ui/qualified/qualified-path-params-2.rs" rel="nofollow">https://github.com/rust-lang/rust/blob/master/src/test/ui/qu...</a> but there was some discussion on zulip which clarifies it: <a href="https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Ambiguous.20associated.20types/near/251210283" rel="nofollow">https://rust-lang.zulipchat.com/#narrow/stream/122651-genera...</a><p>5. Never type<p>TLDR:
Overall I think its important at some point to start isolating what is the language outside of what version of libcore your running.