Re:Ferrous Systems ends partnership with AdaCore
by k8svet on Friday September 29, 2023 @10:56PM
(#37712426)
> Leveraging this experience, we are now ending our partnership so that, by focusing on our core customers independently, we can better support the high-integrity Rust market.
> [...]
> We respect AdaCore's decision to leave the joint Ferrocene project and thank them for contributing to the effort.
Sorry, as someone not playing inside-baseball in the Rust world... to be as charitable as I can... I don't get it.
Re:Ferrous Systems ends partnership with AdaCore
by Xylakant on Saturday September 30, 2023 @03:54AM
(#37713486)
Disclosure: I’m one of the managing directors of Ferrous Systems.
There’s no inside baseball here. Ferrous Systems founded the Ferrocene project in 2020/2021 (1). At some later point in time Ferrous and Adacore decided to partner up for the Ferrocene project. This year, Adacore decided to leave the partnership for reasons only they would be able to explain. They honored their obligations and still do honor the one that remain, so we bear no ill will. We’re still pushing the project forward and are nearing certification. And we’ll have a few exciting things to share in the upcoming days.
All in all, it’s pretty boring, but a lot of paperwork. I‘m honestly surprised why of all of our blog posts this one makes it to the front page a few month after publishing. The way of the HN algorithm are truly mysterious.
(1) the exact date is a bit hard to pin down. We were talking about that much longer, but 2021 marks the founding of critical section, our subsidiary that is the legal entity behind the project.
Re:Ferrous Systems ends partnership with AdaCore
by jcrites on Friday September 29, 2023 @11:14PM
(#37712519)
I was wondering what Ferrocene is. It looks like it's an effort to qualify the existing Rust compiler chain under some standards:
> Ferrocene is a qualified Rust compiler tool chain. With this, Ferrous Systems invested its decade of Rust experience to make Rust a first-class language for mission-critical and functional safety systems.
> For its first release, Ferrocene is a ISO 26262 and IEC 61508 qualified version of the existing open-source compiler, rustc. We plan to work on standards like DO-178C, ISO 21434, and IEC 62278 in the future.
> Ferrocene is a qualified downstream of the main Rust compiler, rustc, which is built and maintained for safety-critical and security use.
> Many vendors fork such compilers - they take a current version of the compiler, change it, qualify it, and then release this version to their customers. This often happens in the name of vendor-locked conveniences.
> Ferrocene is the upstream Rust compiler, rustc, unmodified - thoroughly tested on targets that are not supported by upstream.
Re:Ferrous Systems ends partnership with AdaCore
by woile on Saturday September 30, 2023 @01:56AM
(#37713087)
It is that. IIRC C and C++ are already compliant and they are used in certain industries because of that. The end goal would be to have rust there as well.
Re:Ferrous Systems ends partnership with AdaCore
by jenadine on Saturday September 30, 2023 @03:38AM
(#37713438)
C and C++ have standards, but certification applies to specific implementations only. Ferrocene aims to create a certified Rust implementation with minimal changes to the main compiler (rustc). To achieve certification, detailed documentation or specifications are needed. Ferrocene is doing that: their focus is on meticulous documentation, ensuring the implementation can be certified using standards like ISO 26262.
Re:Ferrous Systems ends partnership with AdaCore
by exDM69 on Saturday September 30, 2023 @04:03AM
(#37713522)
C and C++ have safety certified implementations available for certain platforms from proprietary vendors. The language itself isn't, and neither are Clang or GCC upstream versions. In addition to the compiler, writing safety certified C or C++ code requires external tooling for static analysis etc. And lots of paper work to show due diligence with tools, processes and testing.
I can tell from $WORK experience that writing safety certified C or C++ code is very expensive and not fun.
For my line of work (systems programming for automotive industry), using Rust would be a massive improvement over C or C++. The amount of undefined behavior pitfalls and footguns is a big hindrance to productivity.
Perhaps the most labour intensive part is dealing with integer overflows in a way that keeps static analysis tooling happy. Just the fact that Rust has well defined semantics for overflows would save so much time and money.
Alas, using Rust was not a viable option when the project(s) I work with were started.
Re:Ferrous Systems ends partnership with AdaCore
by rcxdude on Saturday September 30, 2023 @09:05AM
(#37715045)
The question is whether the certified version of them defines the behaviour of the flag sufficiently to be accepted as a means og achieving that outcome. It can be very difficult to do anything not endorsed by the standard, even if it's widely implemented.
Re:Ferrous Systems ends partnership with AdaCore
by Xylakant on Saturday September 30, 2023 @10:26AM
(#37715745)
> Alas, using Rust was not a viable option when the project(s) I work with were started.
We hope things will change. One of the nice things about
Rust is that it can integrate into C in both directions - using C libraries is possible, as well as building components for C codebases. Quite a few of the people we talk to explore (re)writing critical components in rust.
> We respect AdaCore's decision to leave the joint Ferrocene project
There’s certainly more to this than the claimed “ending the partnership to focus on the customers.”
(Submitted title was "Ferrous Systems ends partnership with AdaCore")
> [...]
> We respect AdaCore's decision to leave the joint Ferrocene project and thank them for contributing to the effort.
Sorry, as someone not playing inside-baseball in the Rust world... to be as charitable as I can... I don't get it.
There’s no inside baseball here. Ferrous Systems founded the Ferrocene project in 2020/2021 (1). At some later point in time Ferrous and Adacore decided to partner up for the Ferrocene project. This year, Adacore decided to leave the partnership for reasons only they would be able to explain. They honored their obligations and still do honor the one that remain, so we bear no ill will. We’re still pushing the project forward and are nearing certification. And we’ll have a few exciting things to share in the upcoming days.
All in all, it’s pretty boring, but a lot of paperwork. I‘m honestly surprised why of all of our blog posts this one makes it to the front page a few month after publishing. The way of the HN algorithm are truly mysterious.
(1) the exact date is a bit hard to pin down. We were talking about that much longer, but 2021 marks the founding of critical section, our subsidiary that is the legal entity behind the project.
> Ferrocene is a qualified Rust compiler tool chain. With this, Ferrous Systems invested its decade of Rust experience to make Rust a first-class language for mission-critical and functional safety systems.
> For its first release, Ferrocene is a ISO 26262 and IEC 61508 qualified version of the existing open-source compiler, rustc. We plan to work on standards like DO-178C, ISO 21434, and IEC 62278 in the future.
https://ferrous-systems.com/ferrocene/
More details on what it is: https://ferrous-systems.com/blog/qualifying-rust-without-for...
> Ferrocene is a qualified downstream of the main Rust compiler, rustc, which is built and maintained for safety-critical and security use.
> Many vendors fork such compilers - they take a current version of the compiler, change it, qualify it, and then release this version to their customers. This often happens in the name of vendor-locked conveniences.
> Ferrocene is the upstream Rust compiler, rustc, unmodified - thoroughly tested on targets that are not supported by upstream.
I can tell from $WORK experience that writing safety certified C or C++ code is very expensive and not fun.
For my line of work (systems programming for automotive industry), using Rust would be a massive improvement over C or C++. The amount of undefined behavior pitfalls and footguns is a big hindrance to productivity.
Perhaps the most labour intensive part is dealing with integer overflows in a way that keeps static analysis tooling happy. Just the fact that Rust has well defined semantics for overflows would save so much time and money.
Alas, using Rust was not a viable option when the project(s) I work with were started.
This is a compile-time option in GCC and clang (fwrapv).
We hope things will change. One of the nice things about Rust is that it can integrate into C in both directions - using C libraries is possible, as well as building components for C codebases. Quite a few of the people we talk to explore (re)writing critical components in rust.