Ada and SPARK enter the automotive ISO-26262 market with Nvidia • Hacker News Board

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

#51

Post by pjmlp » Thu, Jun 05, 2025, 10:30 AM UTC

Ygg2 wrote: post #45

pjmlp wrote: post #35

Earlier quoted context omitted.

Less ChatGPT and more language reference manuals, ChatGPT isn't an ancient oracle knows it all, even though Microsoft's marketing sells it as such. Ada has as much zero cost abstractions as C++ and Rust have, and one of the reasons of Ravenscar is even what to turn off for bare metal deployments, and real time OS deployments.

To be fair to ChatGPT, trying to find good documentation for Ada +/- Spark hasn't been quite as smooth sailing as trying to find something for C++. > Ada has as much zero cost abstractions as C++ and Rust have. Couldn't find anything about it (see above), but does Ada come with any monomorphization tricks?

What does that to do with zero cost abstractions as described originally by Bjarne Stroustroup?

The way generics are implemented in Ada compilers is implementation specific.

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

#52

Post by tialaramex » Thu, Jun 05, 2025, 11:15 AM UTC

FirmwareBurner wrote: post #48

pjmlp wrote: post #28

Earlier quoted context omitted.

Ever wondered why F-35 is so famous for software bugs, including in-flight reboot from avionics?

Are those bugs because of C++, or because of bad programing skills and practices? No programming language can save you from bugs if you hire people who don't know what they're doing. I used to work in automotive when a lot of the critical safety SW was only assembly and the end product didn't have any critical bugs. Maybe Lockheed just has shitty programmers who don't know what they're doing because the US defense in…

Not all programming languages are equal when it comes to the skill needed to deliver correct software. Since a large project necessarily can expect only to bring merely ordinary skill to the problem if that's not enough they're in trouble, even if superlative skill would have succeeded that's not what they have.

C++ iterators are a big example of this problem. In the most skilled hands these are a very powerful technology, excellent performance yet tremendous flexibility - but they have a lot of footguns. So do you choose to accept the high defect rates when your ordinary programmers shoot themselves in the foot, or do you neuter this powerful technique to reduce those defects but suffer significant performance problems ?

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

#53

Post by zoom6628 » Thu, Jun 05, 2025, 11:38 AM UTC

seabird wrote: post #8

FirmwareBurner wrote: post #2

But why? The US military abandoned Ada for the F-35 and moved to C++ instead. Is it me or are they moving backwards?

Everything I've heard about it was that it was pressure from contractors because they didn't like training or finding Ada talent. I get that there's more tools for C++ but first class formal verification support and a language that's generally designed to save you from yourself seems like something you would stand your ground on. Ada is supremely good at killing people and/or keeping them un-killed, there's a reason…

THIS.

I knew someone a while back who worked on Patriot missile software. It was Ada. And Patriot still a formidable weapon.

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

#54

Post by smokel » Thu, Jun 05, 2025, 11:46 AM UTC

atlgator wrote: post #16

Wow. I developed in Ada in aerospace 17 years ago. I thought the industry would move toward Rust.

Ferrocene [1] apparently offers an ISO-26262 certified version of Rust. I am thoroughly confused about these certification processes, but it also seems that AdaCore itself [2] has adapted the Rust compiler to be certified as well.

[1] https://ferrocene.dev/

[2] https://www.adacore.com/press/adacore-announces-the-first-qu...

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

#55

Post by qznc » Thu, Jun 05, 2025, 11:52 AM UTC

pfdietz wrote: post #23

Are auto companies going with error correction in memory? I'm thinking of the Toyota unintended acceleration problem. https://www.slideshare.net/slideshow/toyota-unintended-accel...

ECC RAM is normal for safety-critical stuff. Hard to argue for ISO26262 compliance without.

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

#56

Post by fpoling » Thu, Jun 05, 2025, 11:53 AM UTC

anthk wrote: post #36

whytevuhuni wrote: post #34

Earlier quoted context omitted.

I don't know Ada / SPARK, and I've been trying to figure this out. Based on the hallucinations I got from ChatGPT, it seems Ada itself is nowhere near as powerful as Rust in safety, while Ada with SPARK disallows some things I was considering to be quite basic, such as shared aliasing of data. For example, it seems it's not possible to get a sub-string slice reference to an original unbounded string. In rust, a &str…

FFS, ChatGPT doesn't even has a clue on what is talking about.

People often have no clue either explaining why LLMs are so successful.

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

#57

Post by fpoling » Thu, Jun 05, 2025, 12:06 PM UTC

anthk wrote: post #42

pjmlp wrote: post #30

Earlier quoted context omitted.

We are on Ada 202x nowadays being discussed, and in a world where FOSS tool makers have problems making a sustainable business, always changing licenses, there are still 7 Ada vendors selling compilers.

Libre compilers do not impose restrictions on output.

In embedded world restrictions on the output is the last thing of worries while fulfilling various certification requirements can be a big and costly headache.

And from the vendor point of view releasing a compiler under libre license allows for concurrents to undercut one on R&D leading to the compiler and related tools certification. So from business point of view it just makes no sense. This is very different from contributing to, say, clang, where a cost of maintaining own closed fork outweighs any disadvantages of contributing.

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

#58

Post by anthk » Thu, Jun 05, 2025, 12:19 PM UTC

FirmwareBurner wrote: post #48

pjmlp wrote: post #28

Earlier quoted context omitted.

Ever wondered why F-35 is so famous for software bugs, including in-flight reboot from avionics?

Are those bugs because of C++, or because of bad programing skills and practices? No programming language can save you from bugs if you hire people who don't know what they're doing. I used to work in automotive when a lot of the critical safety SW was only assembly and the end product didn't have any critical bugs. Maybe Lockheed just has shitty programmers who don't know what they're doing because the US defense in…

C with underfined behaviours it's far worse than a proved embedded Forth. At least you will know how it will behave with the stack/dictionary and so on.

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

#59

Post by FirmwareBurner » Thu, Jun 05, 2025, 12:21 PM UTC

zoom6628 wrote: post #53

seabird wrote: post #8

Earlier quoted context omitted.

Everything I've heard about it was that it was pressure from contractors because they didn't like training or finding Ada talent. I get that there's more tools for C++ but first class formal verification support and a language that's generally designed to save you from yourself seems like something you would stand your ground on. Ada is supremely good at killing people and/or keeping them un-killed, there's a reason…

THIS. I knew someone a while back who worked on Patriot missile software. It was Ada. And Patriot still a formidable weapon.

You mean the Patriot that ended up getting 28 people killed due to a SW bug?[1] That Patriot?

Let me repeat myself again, Ada won't save you from human bugs. If you hire bad programmers or have bad dev and test practices, there's no magic programming language that will save you from your calculation and logic mistakes. You can code in raw machine code like you're 1960's NASA, and still have less bugs than a clueless vibe coder in Ada/Rust/etc. if you know what you're doing and have the right test and verification processes.

[1] https://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/nod...

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

#60

Post by FirmwareBurner » Thu, Jun 05, 2025, 12:24 PM UTC

anthk wrote: post #58

FirmwareBurner wrote: post #48

Earlier quoted context omitted.

Are those bugs because of C++, or because of bad programing skills and practices? No programming language can save you from bugs if you hire people who don't know what they're doing. I used to work in automotive when a lot of the critical safety SW was only assembly and the end product didn't have any critical bugs. Maybe Lockheed just has shitty programmers who don't know what they're doing because the US defense in…

C with underfined behaviours it's far worse than a proved embedded Forth. At least you will know how it will behave with the stack/dictionary and so on.

Then why did the auto and aerospace industry standardize on C/C++ instead of Forth?

Just because something is sometimes better doesn't mean it's also more economical in production. You're still limited by budget constrains. With that budget you need to hire and/or train SW developer. It doesn't matter that X language might be better if you can't find and/or train people with experience on it. So you're better off using C with safety.