Ada and SPARK enter the automotive ISO-26262 market with Nvidia

Post by steveklabnik » Thu, Jun 05, 2025, 6:28 PM UTC

zppln wrote: post #67

firesteelrain wrote: post #49

Earlier quoted context omitted.

I have worked on safety crucial systems and applications that interact with safety critical systems in a non safety critical language. Each time it never had anything to do with the language and everything to do with systems engineering and project management. The projects that were successful had excellent systems engineering and project management. Language choice was never a factor.

This is my experience as well. People need to ask themselves what benefits Rust would bring to an high assurance system (e.g. DO-178C Level A). You're not gonna want to malloc mid-flight even if you have a borrow checker. The entire point of e.g. DO-178C is to show that the software only does exactly what it is supposed to do under all assumptions and have any derived behavior fed back to the safety process for evalu…

Post by zppln » Thu, Jun 05, 2025, 7:19 PM UTC

steveklabnik wrote: post #81

zppln wrote: post #67

Earlier quoted context omitted.

This is my experience as well. People need to ask themselves what benefits Rust would bring to an high assurance system (e.g. DO-178C Level A). You're not gonna want to malloc mid-flight even if you have a borrow checker. The entire point of e.g. DO-178C is to show that the software only does exactly what it is supposed to do under all assumptions and have any derived behavior fed back to the safety process for evalu…

Rust’s guarantees have little to nothing to do with malloc. Ferrocene isn’t DO-178C certified… yet. But it has similar certifications in other industries.

Post by steveklabnik » Thu, Jun 05, 2025, 9:17 PM UTC

zppln wrote: post #83

steveklabnik wrote: post #81

Earlier quoted context omitted.

Rust’s guarantees have little to nothing to do with malloc. Ferrocene isn’t DO-178C certified… yet. But it has similar certifications in other industries.

And it never will be. In aviation we certify three things: aircraft, engines and propellers. Everything else is at best certifiable , i.e. can be integrated into a product to be certified assuming all deviations, restrictions, caveats etc are considered when doing so. Also, tools follows DO-330 and are qualified . It's their output that should comply with DO-178.

Post by shakna » Fri, Jun 06, 2025, 2:57 AM UTC

whytevuhuni wrote: post #75

shakna wrote: post #41

Earlier quoted context omitted.

I don't think a single point there is true. Ada has had shared aliases since 1995. Its had zero cost abstractions since before then. Slicing memory from a string is in the intro manual, for example. my_var(2 .. 6) Ada doesn't rely on you to be disciplined. [0] Memory safety comes with SPARK. Its a theorum prover. [0] https://blog.adacore.com/memory-safety-in-ada-and-spark-thro...

But doesn't this copy the entirety of that slice? That's not what I meant, I was referring to a shared reference, akin to &str in Rust or std::string_view in C++.

Post by bb88 » Fri, Jun 06, 2025, 3:01 AM UTC

firesteelrain wrote: post #71

zppln wrote: post #67

Earlier quoted context omitted.

This is my experience as well. People need to ask themselves what benefits Rust would bring to an high assurance system (e.g. DO-178C Level A). You're not gonna want to malloc mid-flight even if you have a borrow checker. The entire point of e.g. DO-178C is to show that the software only does exactly what it is supposed to do under all assumptions and have any derived behavior fed back to the safety process for evalu…

I personally know of teams using modern tooling and expansive cloud based CI/CD with safety critical systems and we are talking hundreds of developers. This is in C++ with MISRA standards and DO-178 too.