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

A few days ago, I had ChatGPT compare Rust and Ada. It tended to penalize Ada for its runtime checks and access values (aka pointers). However, ChatGPT didn't account for the fact that many of Ada's runtime checks would need to be manually implemented by developers in other languages. An Ada compiler, can often optimizes these checks away, knowing where they're genuinely needed and where they can be removed. This often explains why speed comparisons between C and Ada code can be misleading, as they rarely factor in the extra manual effort required to make C code equivalently robust with necessary safety checks.

Regarding access values, I listed out some of Ada's various restrictions. Its scope rules prevent referencing objects at deeper levels, objects must be explicitly marked aliased to create an access value to them, and there's far less need for access values (for instance, no pointers are needed to pass parameters by reference). Additionally, Ada offers the ability to dynamically size some objects and reclaim their memory without explicit memory allocation.

After I highlighted these details, ChatGPT admitted it had unfairly evaluated Ada, concluding it's a very safe and robust language, albeit using different techniques than Rust.

Both Ada and spark have zero costs abstractions, they’re designed to run on embedded platforms.

Spark is a different use case from rust - it’s a full prover, and the goal is formal verification, typically in contexts where human life is at stake ( say, you’re writing software for an artificial heart , to take an extreme example ). This comes at the cost of being less flexible, but they’ve been slowly evolving spark so that it can handle increasingly complex cases .

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.

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)

[0] https://blog.adacore.com/memory-safety-in-ada-and-spark-thro...

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

Libre compilers do not impose restrictions on output.

References?

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...

I'm near Detroit which has a huge amount of auto industry, and engineering pay is good across pretty much all disciplines. It'll pay for a happy life and then some as long as relentless title climbing and job hopping isn't your definition of happiness.

Ada is not some exotic thing that requites SF comp. If it's such a major adjustment coming from C/C++ that it's actually causing you trouble, you have other problems.

It's comical bringing up the automotive industry considering that its responsible for AUTOSAR, which is simultaneously widely hated by engineers and completely useless outside the industry.

As a Rust + C++ developer (in medical right now, and vehicle before that) I see no reason why I couldn't also pick up Ada as one of many skill sets. I have an Ada95 manual on my bookshelf from years ago that I bought out of curiosity -- frankly for senior level talent the language syntax is the easiest thing to pick up it's the intricacies of an existing code base and business domain that is the hard part of joining a new project and that is generally language independent.

Arguably picking up Rust -- with its frankly exotic value passing and ownership semantics -- is much harder than learning Ada.

There are 7 compiler vendors still in business, if anything Ada's domain is one of the fews where paying for tools one needs to do their job is still a thing, like in most professions.

> Ada's developmemt tools are fewer, less featued

Such as?

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 ?

The C++ job market is full of two kinds of developers.

Mediocre talent that struggles with the language and continually make use after free bugs.

And elitist arrogant developers in love with the language, skilled in its use, who continually make use after free bugs.

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.

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.