Also we are now on Ada 202x already, quite different from Ada83, that some Rust folks keep comparing their favourite language with.
You get all the niceties of a language more in line with Object Pascal productivity, formal proofs, a RAII approach safer than C++ (controlled types, automatic stack types, unbound collection types), industry baremetal profiles like Ravenscar, and the recent versions are in the process of having affine types as well (aka borrow checker).
DoingIsLearning · 20h ago
> industry baremetal profiles like Ravenscar
I understand the value proposition of Formal Verification with Spark.
But for me the killer features with Ada, thinking specifically of embedded systems is:
- The expressiveness you gain with Ada's Type System
- The Ravenscar profile (very impressive work from a small group of folks in the IRTAW group)
whytevuhuni · 22h ago
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 -> &str signature is trivial.
So it seems Ada still relies on discipline, while SPARK does not have the zero-cost abstractions that C++ and Rust have.
If that's true (is it?), then I'd definitely choose C++/Rust over Ada any time, since performance is very important to me.
Agingcoder · 21h ago
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 .
pjmlp · 22h ago
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.
anthk · 21h ago
Seriously, if these people use ChatGPT to seek new knowledge, we are doomed. They are utterly clueless.
Ygg2 · 20h ago
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?
pjmlp · 18h ago
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.
Ygg2 · 14h ago
How exactly are you going to implement generics in a way that's:
> What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
without monomorphizing the generics?
pjmlp · 10h ago
By letting the compilers decide the best way to implement them.
Also I find funny this point of view on Ada, given the poor examples WG21 has added into the C++ standard library, that will never be fixed due to never-ending ABI drama.
Ygg2 · 10h ago
Look. I'm not against Ada. Not my favorite language but definitely huge step in the right direction.
With that said. How does:
> By letting the compilers decide the best way to implement them.
Get you to zero cost generics. What if implementor just says "let them eat memory" and boxes the generic.
pjmlp · 10h ago
By the same way std::regexp gives you zero cost abstractions in handling regular expressions in C++.
shakna · 20h ago
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.
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++.
shakna · 1h ago
It's a slice, with basically the same implementation as std::string_view. [0]
If you want a copy, with Unbounded String, you'll need to call To_String on the slice.
Doing it normally should create a copy of the value, as far as I can tell. Unless you use it to create a renamed variable or by-reference parameter, the same way you can create references in C++.
I think the closest thing to a &str in Ada would be an "access String" or "access constant String", which you would get either from an allocated "String" or from a declared "aliased String". You'd create a subslice with "string(x..y)'Access". Though I'm not sure whether that actually works without explicitly declaring an array of "aliased Character", the Manual is dense (as with C++, it's nearly meaningless unless you already know what it's supposed to mean) and the tutorials generally avoid talking about access objects.
shakna · 1h ago
That's for String, not the referenced Unbounded String.
whytevuhuni · 10h ago
Thank you! I assume 'Access types are not memory-safe, right? Is there a SPARK equivalent which still does not copy (i.e. it only references) that is memory safe?
To be more specific, how would one implement something like a "Get_First_Word" or "Trim_Whitespace" without copying?
LegionMammal978 · 10h ago
I think it's supposed to be safe in Ada by default? As far as I can tell, basic allocated objects cannot be deallocated without an "unchecked" operation, and access objects created from "aliased" declarations are subject to scoping rules [0]. (If you want to know the full details, go figure out however "accessibility levels" are supposed to work [1].) It should preclude functions from returning access objects without a "prefix'Unchecked_Access" operation. I'm not sure how SPARK's borrowing system is tied into all of this.
FFS, ChatGPT doesn't even has a clue on what is talking about.
fpoling · 16h ago
People often have no clue either explaining why LLMs are so successful.
cashsterling · 1d ago
Yeah... my intro CS class was in C and Ada95 (I'm not a CS guy btw, just took the class). I actually preferred Ada over C... but continued to program in C for other classes because of compiler availability; I had to do all my Ada programming on Sparc workstations at school.
I personally think that AdaCore, and friends, missed an opportunity in the early 2000's to fully embrace open source... they left a big gap which Rust has filled nicely.
I still think Ada is a great programming language. When a question comes up along the lines of: "what's the best programming language nobody's heard of?", or "what's the best programming language that is under used?" Ada is usually my first answer. I think other good answers include F#, <insert LISP flavor>, Odin, Prolog, Haxe, and Futhark (if you're into that sort of thing).
pjmlp · 23h ago
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.
anthk · 20h ago
Libre compilers do not impose restrictions on output.
fpoling · 16h ago
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.
pjmlp · 18h ago
As long as there are enough people around to actually work on them.
smokel · 16h ago
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.
It happened to me. I sure wasn't elderly. The only thing that stopped a crash was shifting into neutral and hitting the brakes.
Then, I was sitting there with the engine revving loudly for no reason. Car behind me started backing up. I decided to just shut it off and turn it back on. It went away.
Scary stuff. Especially since I had no idea why it happened.
FirmwareBurner · 1d ago
But why? The US military abandoned Ada for the F-35 and moved to C++ instead. Is it me or are they moving backwards?
seabird · 1d ago
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 you still see it kicking around in defense and aerospace despite the common perception that it's a bygone relic.
zoom6628 · 17h ago
THIS.
I knew someone a while back who worked on Patriot missile software. It was Ada. And Patriot still a formidable weapon.
FirmwareBurner · 16h ago
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.
The Patriot failures were the result of floating point error. Ada provides facilities specifically to deal with this, while you're left rolling your own in C/C++. Of course Ada won't save you from human bugs, but it's silly to say that you're no better off with a language giving you everything it can to avoid them than one that is a notorious fuckup dispenser.
anthk · 14h ago
It will help a lot still. But as I said, Forth it's better than raw ASM.
On integers casted into floats, a Forth programmer would use a fixed point in a much saner way, they had experience for decades on it.
FirmwareBurner · 20h ago
>Everything I've heard about it was that it was pressure from contractors because they didn't like training or finding Ada talent.
Do you think the auto industry will have a easier time finding Ada talent at their pay rates? Or that talent will want to specialize into Ada just to pigeonhole themselves into the Automotive jobs market?
seabird · 12h ago
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.
cmrdporcupine · 16h ago
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.
FirmwareBurner · 16h ago
> I see no reason why I couldn't also pick up Ada as one of many skill sets
Low wages and the negative resume drive development might be reasons.
Believe it or not, pigeon holing yourself in niche/uncool tech for years, can and will negatively impact your future hiring prospects at good jobs, since hiring in tech is broken and HR selects resumes on buzzwords and on your "last X years of experience in Y framework".
johnnyjeans · 1d ago
you mean the plane plagued with software development issues[1][2]?
even ignoring the obnoxious yellow journalism, i'm not sure it's a shining beacon of best practices. or that replacing one ancient language with an even more ancient language is "moving forwards."
particularly when the language you're replacing was explicitly designed for your domain, and the language you're replacing it with is an entropic event horizon from which no coherent thoughtform can escape.
It was not for technical reasons. They needed more programmers and C++ had larger user base.
Ada is technically better choice.
CivBase · 1d ago
It has more to do with tooling than programmers. C++ is used everywhere so there are many commercial tools to support it. Not so much for Ada.
Ada's developmemt tools are fewer, less featued, and more costly due to low demand.
pjmlp · 23h ago
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.
johnisgood · 1d ago
> Ada's developmemt tools are fewer, less featued
Such as?
dardeaup · 1d ago
Regarding the number of options, C++ has quite a few IDEs: Visual Studio, Xcode, VSCode, CLion, and probably more (Oracle probably still sells the one they had for Solaris). For command-line compilers, C++ has: Visual Studio, Xcode, g++, clang++, IBM C++ compilers for their OSs, Oracle compilers for Solaris, etc.
For Ada, is there anything other than AdaCore? Is that the same as GNATStudio?
Each of those has an optional IDE. All of the IDEs you mentioned also support Ada.
RavSS · 1d ago
You don't have to use AdaCore's GNAT Studio. You can quickly get going with Ada/SPARK using Visual Studio Code, as there is an LSP extension for it published by AdaCore themselves.
p_l · 1d ago
The kind of tooling you need for avionics is not necessarily the kind of tooling you use for non-safety critical code.
None of the tools mentioned, other than in limited level IDEs (for practical purposes in safety critical C++ expect some niche variation of Eclipse just like if you used Ada) are valid for the F-35 project.
cjbgkagh · 1d ago
I think IBM Rational Ada was a thing back then. Never used it but heard stories about it.
cjbgkagh · 1d ago
I should add, what I was told is that they were amazing, especially the pre-IBM Rational stuff. Rational was acquired by IBM in 2003. I was working on tech adjacent to the JSF (F35). I was told by a guy working on the JSF that the extra bugs from C++ would mean better job security and he was 100% right. It’s pretty much that conversation that triggered my move into high tech and away from military. I think it’s a shame that IBM happened to Rational, a lot of nascent good ideas pretty much disappeared or were mangled beyond recognition.
ryao · 22h ago
Netbeans is the Solaris IDE. It is free.
CivBase · 1d ago
Want a compiler? I hope you like GNAT.
Want an IDE? I hope you like GNAT Pro Studio.
Want a static analysis tool? I hope you like CodePeer.
Ada compilers: PTC ApexAda, GreenHills Ada, Static analysis tools for Ada: CodePeer, ConQAT,Fluctuat,,LDRA Testbed,MALPAS,Polyspace,SofCheck Inspector,Squore,Understand. Similar list for all other things.
When C++ was chosen for F-35 there were more verification tools to Ada than C++.
sam_bristow · 21h ago
For C++ on similar systems its becoming more and more "I hope you like LLVM with the serial numbers filed off". Lots of the tool vendors are sunsetting their bespoke compilers. Most of the vendor IDEs have always been Eclipse with a bunch of bundled plugins.
bb88 · 1d ago
SPARK formal verification is a big win. Ada is also simpler than C++.
However, the tooling for Ada was never as good as C++ tooling.
firesteelrain · 1d ago
GNAT, AUnit, VectorCAST are all good. AUnit isn’t compatible with Ada 95 though
pjmlp · 1d ago
Ever wondered why F-35 is so famous for software bugs, including in-flight reboot from avionics?
fransje26 · 20h ago
Since Lockheed struck a deal with the government allowing them to no longer communicate the number of issues encountered on the F-35 program, news reports have only been writing about how it has been the best thing since sliced bread. (Save for the mishaps happening from time to time..)
Which is entertaining, because until that point (2021, if memory serves?) it was encountering an ever increasing number of critical issues needing resolving, a double dozen of which would be lethal to the pilot flying. The backlog stood at 800+ issues at the time.
Some of the software issues were so serious that they were considered beyond salvageable at the time, despite having already gone through a full re-write from scratch cycle..
FirmwareBurner · 19h ago
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 industry is incompetent and the US SW jobs market top heavy where talent who does know how to use C++ right goes to big-tech and not on-site at some defense contractor? To me that's not the fault of C++.
tialaramex · 17h ago
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 ?
FirmwareBurner · 16h ago
>C++ iterators are a big example of this problem. [...] but they have a lot of footguns.
Bigger than coding in assembly?
>when your ordinary programmers shoot themselves in the foot
Then don't hire non-name foot shooting programmers off the street. Hire versed engineers with background in programing for safety critical systems, then have them train the code monkey engineers on the right way to think and work. Like I said, skill issue, not language issue.
cmrdporcupine · 15h ago
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.
FirmwareBurner · 15h ago
And you think enthusiasts of niche languages like Ada, will be more skilled and less elitist than C++ devs?
cmrdporcupine · 15h ago
I think I'm tired, after 20+ years of being around the language, of hearing C++ developers tell people "they're holding it wrong" every time something blows up. Blaming the victim.
C++ is a language seemingly designed with footguns built in on purpose. Even worse it has a community full of elitism and obscurantism.
Rust isn't perfect (I have my gripes), but it has the right idea with ownership management at the static type system level. Ada has its own positives around explicitness and bounds checking etc
C++ for new projects in safety critical sectors makes zero sense to me.
bb88 · 1h ago
> Even worse it has a community full of elitism and obscurantism.
I've never experienced that per se, I have experienced it in other fields or orgs where the bar to entry is super high. And keeping the bar to entry is often the goal of those that are elitist. Google interviews were that way 15 years ago.
I think the issue I keep coming back to with type safety is how do you make sure a value in meters is not mistakenly used as feet without some kind of translation. If you're going to have type safety, I feel the language should prevent that.
And if it can't prevent that, then it's not really "typesafe".
anthk · 16h ago
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.
FirmwareBurner · 16h ago
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.
gneuromante · 1d ago
It was the US military who moved backwards.
firesteelrain · 1d ago
Language selection is no panacea for bad systems engineering or poor project management
anthk · 20h ago
It helps on security and correctness. Either you are a Forth like guy/gal stating how a firmware will work at every level (low, med, high, every one), cutting down every flaw by getting it as small and predictable as possible (even by ditching floats for rationals and decimal scaling), or a high level Lisp/CL/Java/C# guy with a garbage collector and some memory safety. And Java/C# and some Lisps aren't nowhere as strict on that as ADA.
firesteelrain · 19h ago
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.
zppln · 15h ago
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 evaluation. Software can never in itself make a system safe.
All that aside, modern tooling may be more ergonomic etc so I'm not saying languages like Rust shouldn't be considered, they just aren't as useful here as I think a lot of people assume.
steveklabnik · 10h ago
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.
zppln · 9h ago
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.
steveklabnik · 7h ago
Sure, yes, I always end up saying “certified” instead of “qualified” for some reason. Thanks.
firesteelrain · 14h ago
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.
bb88 · 1h ago
I don't think it's fair to say C++ is safe and reliable as is. The only way it could be made safe is with a restricted version of C++.
I'm reminded by mozilla's sign "You must be this tall to write threaded code." [1] How much do you restrict your language and libraries to make it safe? Like custom templates? How do you define ownership of objects and lifetimes -- or just malloc everything all at once?
"Nvidia Security Team: “What if we just stopped using C?”, 170 comments (2022), https://news.ycombinator.com/item?id=42998383
This is the original announcement from 2020,
"SPARK/Ada Journey to Adoption"
https://youtu.be/DZSSyWlsb28?si=vh4gO-LT2N3Skaql
Also we are now on Ada 202x already, quite different from Ada83, that some Rust folks keep comparing their favourite language with.
You get all the niceties of a language more in line with Object Pascal productivity, formal proofs, a RAII approach safer than C++ (controlled types, automatic stack types, unbound collection types), industry baremetal profiles like Ravenscar, and the recent versions are in the process of having affine types as well (aka borrow checker).
I understand the value proposition of Formal Verification with Spark.
But for me the killer features with Ada, thinking specifically of embedded systems is:
- The expressiveness you gain with Ada's Type System
- The Ravenscar profile (very impressive work from a small group of folks in the IRTAW group)
For example, it seems it's not possible to get a sub-string slice reference to an original unbounded string. In rust, a &str -> &str signature is trivial.
So it seems Ada still relies on discipline, while SPARK does not have the zero-cost abstractions that C++ and Rust have.
If that's true (is it?), then I'd definitely choose C++/Rust over Ada any time, since performance is very important to me.
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 .
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.
> 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?
The way generics are implemented in Ada compilers is implementation specific.
> What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
without monomorphizing the generics?
Also I find funny this point of view on Ada, given the poor examples WG21 has added into the C++ standard library, that will never be fixed due to never-ending ABI drama.
With that said. How does:
> By letting the compilers decide the best way to implement them.
Get you to zero cost generics. What if implementor just says "let them eat memory" and boxes the generic.
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.
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...
If you want a copy, with Unbounded String, you'll need to call To_String on the slice.
[0] https://sites.radford.edu/~nokie/classes/320/std_lib_html/ad...
I think the closest thing to a &str in Ada would be an "access String" or "access constant String", which you would get either from an allocated "String" or from a declared "aliased String". You'd create a subslice with "string(x..y)'Access". Though I'm not sure whether that actually works without explicitly declaring an array of "aliased Character", the Manual is dense (as with C++, it's nearly meaningless unless you already know what it's supposed to mean) and the tutorials generally avoid talking about access objects.
To be more specific, how would one implement something like a "Get_First_Word" or "Trim_Whitespace" without copying?
[0] https://www.adaic.org/resources/add_content/docs/craft/html/...
[1] http://www.ada-auth.org/standards/22rm/html/RM-3-10-2.html
I personally think that AdaCore, and friends, missed an opportunity in the early 2000's to fully embrace open source... they left a big gap which Rust has filled nicely.
I still think Ada is a great programming language. When a question comes up along the lines of: "what's the best programming language nobody's heard of?", or "what's the best programming language that is under used?" Ada is usually my first answer. I think other good answers include F#, <insert LISP flavor>, Odin, Prolog, Haxe, and Futhark (if you're into that sort of thing).
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.
[1] https://ferrocene.dev/
[2] https://www.adacore.com/press/adacore-announces-the-first-qu...
https://www.slideshare.net/slideshow/toyota-unintended-accel...
Also, unintended acceleration seems to have gone away. The control hardware has been changed; driver age, not so much.
Then, I was sitting there with the engine revving loudly for no reason. Car behind me started backing up. I decided to just shut it off and turn it back on. It went away.
Scary stuff. Especially since I had no idea why it happened.
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 you still see it kicking around in defense and aerospace despite the common perception that it's a bygone relic.
I knew someone a while back who worked on Patriot missile software. It was Ada. And Patriot still a formidable weapon.
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...
On integers casted into floats, a Forth programmer would use a fixed point in a much saner way, they had experience for decades on it.
Do you think the auto industry will have a easier time finding Ada talent at their pay rates? Or that talent will want to specialize into Ada just to pigeonhole themselves into the Automotive jobs market?
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.
Arguably picking up Rust -- with its frankly exotic value passing and ownership semantics -- is much harder than learning Ada.
Low wages and the negative resume drive development might be reasons.
Believe it or not, pigeon holing yourself in niche/uncool tech for years, can and will negatively impact your future hiring prospects at good jobs, since hiring in tech is broken and HR selects resumes on buzzwords and on your "last X years of experience in Y framework".
particularly when the language you're replacing was explicitly designed for your domain, and the language you're replacing it with is an entropic event horizon from which no coherent thoughtform can escape.
[1] - https://www.dote.osd.mil/Portals/97/pub/reports/FY2024/other...
[2] - https://www.gao.gov/products/gao-24-107177
Ada is technically better choice.
Ada's developmemt tools are fewer, less featued, and more costly due to low demand.
Such as?
For Ada, is there anything other than AdaCore? Is that the same as GNATStudio?
Edit* - fixed Ada capitalization
Each of those has an optional IDE. All of the IDEs you mentioned also support Ada.
None of the tools mentioned, other than in limited level IDEs (for practical purposes in safety critical C++ expect some niche variation of Eclipse just like if you used Ada) are valid for the F-35 project.
Want an IDE? I hope you like GNAT Pro Studio.
Want a static analysis tool? I hope you like CodePeer.
Want to do unit testing? I hope you like Rapita.
When C++ was chosen for F-35 there were more verification tools to Ada than C++.
However, the tooling for Ada was never as good as C++ tooling.
Which is entertaining, because until that point (2021, if memory serves?) it was encountering an ever increasing number of critical issues needing resolving, a double dozen of which would be lethal to the pilot flying. The backlog stood at 800+ issues at the time.
Some of the software issues were so serious that they were considered beyond salvageable at the time, despite having already gone through a full re-write from scratch cycle..
Maybe Lockheed just has shitty programmers who don't know what they're doing because the US defense industry is incompetent and the US SW jobs market top heavy where talent who does know how to use C++ right goes to big-tech and not on-site at some defense contractor? To me that's not the fault of C++.
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 ?
Bigger than coding in assembly?
>when your ordinary programmers shoot themselves in the foot
Then don't hire non-name foot shooting programmers off the street. Hire versed engineers with background in programing for safety critical systems, then have them train the code monkey engineers on the right way to think and work. Like I said, skill issue, not language issue.
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++ is a language seemingly designed with footguns built in on purpose. Even worse it has a community full of elitism and obscurantism.
Rust isn't perfect (I have my gripes), but it has the right idea with ownership management at the static type system level. Ada has its own positives around explicitness and bounds checking etc
C++ for new projects in safety critical sectors makes zero sense to me.
I've never experienced that per se, I have experienced it in other fields or orgs where the bar to entry is super high. And keeping the bar to entry is often the goal of those that are elitist. Google interviews were that way 15 years ago.
I think the issue I keep coming back to with type safety is how do you make sure a value in meters is not mistakenly used as feet without some kind of translation. If you're going to have type safety, I feel the language should prevent that.
And if it can't prevent that, then it's not really "typesafe".
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.
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 evaluation. Software can never in itself make a system safe.
All that aside, modern tooling may be more ergonomic etc so I'm not saying languages like Rust shouldn't be considered, they just aren't as useful here as I think a lot of people assume.
Ferrocene isn’t DO-178C certified… yet. But it has similar certifications in other industries.
Also, tools follows DO-330 and are qualified. It's their output that should comply with DO-178.
I'm reminded by mozilla's sign "You must be this tall to write threaded code." [1] How much do you restrict your language and libraries to make it safe? Like custom templates? How do you define ownership of objects and lifetimes -- or just malloc everything all at once?
[1] https://bholley.net/blog/2015/must-be-this-tall-to-write-mul...