But why? The US military abandoned Ada for the F-35 and moved to C++ instead. Is it me or are they moving backwards?
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.
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?
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".
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.
I dunno about Detroit since I don't live there, but in Europe the auto industry is on a major downturn with cost cutting, layoffs and hiring freezes. Good luck getting hired anywhere now if you're laid off from the Auto industry and your specialty is some niche stuff only used in the auto industry. Also, IIRC, the company I worked for recently laid off 35% staff at their Auburn Hills office overnight so I doubt the situation around Detroit is as rosy as you make it seem.
> If it's such a major adjustment coming from C/C++ that it's actually causing you trouble, you have other problems.
Like I said, there should be no problem for a (skilled) programmer to adjust from C++ to Ada or vice versa, the problem is convincing HR to hire you on that premise. Ask me how I know (see my username).
Gone are the days of the SW generalists programmer, who would be hired with the expectation to learn on the job the new language used at that job, companies now are only looking for people with X on-the-job YoE on that programming language or framework, not self taught people coming from other programing languages.
This is not something you can control, it's the hiring market that's broken, so you can only adapt to it by not pigeonholing yourself in things that might be a career dead-end.
>It's comical bringing up the automotive industry considering that its responsible for AUTOSAR
AUTOSAR did what it was supposed to do: be a vendor lock in program for German bureaucratic companies and job security program for workers in that industry. That's what Germany and German companies do best: create massive amounts of bureaucracy requirements as a moat for an industry they have a foothold in, then sell you the solution. Why do you think SAP is also German?
You don't outright lose years of experience writing C and C++ just because you learned Ada. You're not going to leave a decade of C experience off your resume just because it wasn't the primary language in your last position. Ada isn't for frontend web development where new "technology" gets chewed up and spat out every year or two. It shines in firmware. There's plenty of vendors that haven't moved past C99.
Chalking up a hypothetical appreciable Ada marketshare in automotive as "niche stuff only used in the auto industry" doesn't make sense in that it sees plenty of use in aerospace, defense, and medical. The point of me bringing up AUTOSAR is that Ada is nowhere close to the pigeonhole scenario that AUTOSAR is.
In the world where you only have Ada experience, and you're not a bad programmer, but HR departments are giving you grief, just lie on your resume. Fuck em. We both know that it's not a major adjustment, so brush up on details before you're interviewed and if they asked what you used C/C++ just say you're not at liberty to speak about it. Nobody is going to hit you with anything along the lines of whether or not it's true that monads are just monoids in the category of endofunctors.
How does that help when nobody is hiring right now and you're competing with thousand of laid off engineers?
>so brush up on details before you're interviewed
How do you get interviewed in the first place if they're screening your resume out due to not having the experience with the programming languages they're looking for?
Like I said, having niche languages sends your resume in the bin.
>if they asked what you used C/C++ just say you're not at liberty to speak about it
Unless you worked for government intelligence, this type of response gets you rejected immediately here in Europe/Germany, since they have 100 other candidates who can speak about what they did. Why would they bother with you when you're already making their life hard from the interview stage?
I feel like your US centered viewpoint is way off from the reality of where I live.
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.
2. In mission critical systems we always used fixed point fractional numbers in C as a representation of floats, to avoid floating point issues, so any issues of the language are moot.
Of course I know that you can do all of this stuff in C. I did it for years. I just don't think there's any sort of honor or expression of skill in getting your balls busted by this stuff being an afterthought, it's just annoying. I know your response will be "get better", and I did, countless people have, and we all still appreciate that these nuisances can be taken care of by the language.
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...
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
Could you elaborate on this please? What is "high tech" here?
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.
Each of those has an optional IDE. All of the IDEs you mentioned also support Ada.
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.
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.
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".
Nominal typing - you declare meter and float to be separate types. Ada makes that simple. Both Rust and Ada support that, and it's normal practice in Ada to declare separate types for every unit.
Sorry but I' can't entertain such broad generalizations of people. That's like hearing a woman saying all men are trash.
I agree with comments on the technicality of the language but if you start attacking people, I'm out.
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.
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...
> or just malloc everything all at once?
Yes! But here's the thing: this isn't done due to the footguns associated with memory management, it is done because you want as little dynamic behavior as possible. For Level A software you need to show that your software has both bounded execution time and memory usage, and be robust against all inputs. Achieving that is so much easier without dynamic memory management.
Also, another thing to keep in mind is that DO-178 has you show that your software requirements are traceable to system requirements, your software design to your software requirements, your source code to your software design and your object code to your source code. But testing should be requirements based. So if your compiler inserts a bounds check now you have object code not traceable to source code and for which you won't have coverage because your requirement mention it. But what if you mention it in your requirements? Well, then you'd have to implement it manually in source code to uphold traceability anyway...
I will caveat the above by saying that other players may interpret things differently or have found ways to do things more cleverly.
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.