That is amazing. There are so many good links in the peer comments. I worked at STMicro, then briefly at Arm, then at IAR. I never once encountered Ada. Two separate worlds!
It's technically "allowed" by ISO26262, but I've never encountered anybody using it for anything in automotive. The automotive software ecosystem is dominated by C and firmly kept that way by the bevy of tools in use (e.g. flavors of AUTOSAR, Mathworks Simulink, etc.).
That's not to say that nobody is using, or hasn't used, Ada in automotive, but it would seem likely vestigial rather than up and coming based on my exposure to that industry.
I was thinking of this, which is a little vague, but the software will have some ASIL classification I'm sure, but maybe is not typical automotive software. Article mentions certain firmware.
I remember when it came out. It was a bear when it came to CPU time for compilation. At UIC, where CPU time was subject to weekly quotas, students in the Ada team had to work in teams because they'd use up their quota of CPU time (you'd get a fresh allocation of CPU each week and once you went over your quota you couldn't log back in until you got a new allocation) in one programming session and would have to log in to a different account to continue working the next day.
I don't have any practical experience with the language, but based on the spec, it sounds like Ada generics would have much the same problem wrt compilation times as C++ templates do, at least if you try to fully optimize them (i.e. avoid boxing and similar techniques to allow generic code to be compiled just once, instead of once for every unique instantiation in every translation unit).
Not really, they need to be explicitly defined before use.
Which then thanks to packages, they can be reused across several projects when similar type parameters are required.
So you only generate List(T => Integer) once for the whole project, when project architecture is properly done.
A scenario that eventually might be possible in C++, around C++23 time frame, taking into consideration how long the modules infrastructure might need to mature.
In many ways Rust fills part of the conceptual space that Ada was attemptiong to fill. Both are very concerned with safety.
Except Ada was military/government mandated, and the syntax is probably the opposite of Rust: very verbose, very wordy. And the concept of type inference is anathema to the Ada mindset, where everything is explicitly... explicit.
I've never used Ada for work but I went through a couple years where I enjoyed playing with the language as a sort of C++ alternative. I ... kind of? like it, but then I learned Pascal and Modula-2 before I ever learned C, so...
One of the nice things about the verbosity is that it's really easy to read. I've been working with code from the late 90's for some aircraft and it makes it really easy to review and get into the code (when well-written). The other thing is that the strong types are really powerful. If Ada compiles, then the only things that you have to worry about is if your logic is right or if you remembered to init an array.
Also, whereas Ada is perfectly fine with introducing runtime overhead, Rust takes a zero runtime cost approach when possible, otherwise it doesn't offer that feature as part of the language.
Robotics (as in 6dof teach-in industrial robot arms you'd find on a factory floor). At least that used to be the case 30 years ago, but I doubt that changed.
