Live data from Hacker News

Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

manufacturing.net

191–200 of 203 posts

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#191

Earlier quoted context omitted.

I'm not super knowledgeable about Rust, but I have tried poking at it a few times, so... you know. Rust seems to be extremely focused on memory safety. Meanwhile Ada is much more focused on correctness in general. Restricting the discussion to simply memory safety ignores, well, most of anything that might be programmed. Ada also has more memory safety options than people tend to talk about. As others have mentioned,…

I like Rust, but my interest in it dwindled when I realized the safety/correctness focus was almost exclusively on memory safety, with regard to its "value add". Ada's type system offering things like custom, incompatible, integer ranges (even if they cover the same range, cross-type assignment requires explicit conversion) was the safety I needed for work. Memory safety is great, and a worthwhile goal, but was not t…

I actually wouldn't say that Rust's safety/correctness focus is exclusively on memory safety. I think it's an easy and clear thing to point to, but compared to C, you've got the following features:

- Nullable types (Option), maybe-error results (Result) etc. that force you to check whether you're looking at the right variant. You can't have bugs where you fail to check the error value and you use invalid/meaningless data, because you syntactically cannot express access to the data. This does often manifest as avoiding NULL pointer dereferences, which is technically a form of memory unsafety, but it's really preventing a logic bug. (For instance, this would have made the "goto fail" bug unnatural to write; that one was returning err = 0 as if it were an error, which you can't really do in the Result model.)

- More generally, sum types / tagged enums and the match and if let constructs, which enforce at compile time that you're accessing data from the right variant.

- Locked data that enforces that you hold the lock when you access the data, using similar means. You can enforce that there's no direct access to the data except through the lock wrapper, and more importantly, you can enforce that the lock stays locked as long as someone holds a direct reference to the data (i.e., that you can't leak a reference to that data and use it after you've released the lock).

- Safe threading/concurrency via labeling which types can be moved between or shared across threads. Again, this is technically a form of memory unsafety (data races) but it's more about logic.

- Typestate. You can avoid bugs where you use some logical resource when it's in the wrong state (read/write a closed file handle, send protocol data while you're still handshaking, etc.) if your API consumes ownership of the object in one state and returns the object in another state, and you don't have methods on objects of the wrong state. Rust pre-1.0 had typestate as a language-level feature, but it's straightforward to implement using the typesystem and the ownership model.

Really, I would say the core feature of Rust is a richer type system and the system of ownership and shared/mutable references. The most obvious thing to do with it is to prevent buffer overflows and use-after-frees, but it's not the only thing. (And that's also why I mentioned safe dynamic allocations, which rely heavily on the ownership system; without it, it's still pretty easy to prevent buffer overflows for static allocations.)

I don't have a sense of where Ada lines up on these. I know it has a much richer type system than C too, so it's possible it answers many of the goals besides safe dynamic allocations. I just personally see the benefit of Rust as more than just memory safety.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#192
post #190
post #180

Earlier quoted context omitted.

The Rust compiler had some severe bugs in the past which undermined the effectiveness of the memory safety. There is the saying in software engineering that the number of undiscovered errors in the system is proportional to the number of discovered errors. On the other hand Ada compilers used to be subjected to strict validation procedures in the past, and the AdaCore toolchain has an ISO 26262 and IEC 61508 qualific…

> There is the saying in software engineering that the number of undiscovered errors in the system is proportional to the number of discovered errors. I think that's true for software developed under similar processes, but (for instance) if you're comparing software that has unit tests and software that doesn't, the constants are probably wildly different. Your tests (or even the process of thinking about writing tes…

> I think that's true for software developed under similar processes

Of course, this is not a law of nature, but simply a reasonably plausible heuristic, which somewhat justifies my reluctance to a new technology, which was received with much enthusiasm.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#193
post #188

Earlier quoted context omitted.

My experience is vastly different from yours. I've been using Ada as my main language for personal stuff for some years now... I can't quite recall when, but call it 5+ years? I won't say I've never run into some kind of problem with Ada on gcc (aka FSF GNAT), but it's been pretty minimal and easily avoided. I think it's been a grand total of two or three bugs that I've known of in that time. I've also run into known…

As I said, I tried the FSF version at about 2018. Might be way better now, I don't know. My experience with gcc (C, not C++) for personal projects is exactly zero bugs. So, you see, experiences can differ ;-). When saying "you need the support contract" I mean getting the commercial compiler version. I think (theoretically?) AdaCore does not charge you for the compiler, but for support. And you only get access to the…

I mean, I was using FSF GNAT in 2018. And a few years before that, and some after it. I have a hard time imagining an experience even remotely described as unusable.

I do wish AdaCore didn't leave the compiler situation so confusing. It's just enough to be a consistent distraction.

Basically they all come from the same source. The GPL version gets a yearly release that, afaik is basically the commercial one (presumably not including anything customer specific). FSF then has a bit of a more ambiguous relationship with the GPL version, but AdaCore maintains that too. Probably around 2018 I think there was more effort being put into eliminating any remaining differences between the GPL and FSF versions.

They also have some further libraries that are available. At least some (maybe all? I don't know) are available under the GPL too. I have no idea how the pricing on that stuff goes. That strays from the compiler side of things though.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#194
post #191

Earlier quoted context omitted.

I like Rust, but my interest in it dwindled when I realized the safety/correctness focus was almost exclusively on memory safety, with regard to its "value add". Ada's type system offering things like custom, incompatible, integer ranges (even if they cover the same range, cross-type assignment requires explicit conversion) was the safety I needed for work. Memory safety is great, and a worthwhile goal, but was not t…

I actually wouldn't say that Rust's safety/correctness focus is exclusively on memory safety. I think it's an easy and clear thing to point to, but compared to C, you've got the following features: - Nullable types (Option ), maybe-error results (Result ) etc. that force you to check whether you're looking at the right variant. You can't have bugs where you fail to check the error value and you use invalid/meaningles…

Interesting. The main reason I lost interest in Rust is because I found the type system to be too poor (there should be a better alternative to "rich" in this context, but I can't think of it right now).

Off the cuff, I'd say Ada addresses all of those problems. In case you're interested, I'll leave a few terms that might be useful in delving further.

- Nullable types + sum types. Pointers can be declared "not null" which basically works as it says. Sum types exist as discriminated and variant records. Variants can be immutable or mutable, and obviously work to do the typical Option, Result, etc stuff.

- Locked data. Protected types do this. I imagine details might differ, but I know nothing about how Rust does this and haven't messed with them much or at all in Ada.

- Task types. I'm tempted to say more, but the little details matter so much for this kind of thing so I probably shouldn't. But Ada has tasking and concurrency mechanisms built-in to the language.

- Typestate. Compiler errors for this sort of thing are not immediately obvious to me. I can think of several options to try using even just the features I already mentioned, but I'm not sure what would or would not be detectable at compile-time. Catching incorrect usage and preventing it from causing trouble is more trivial, but just not the same.

The simplest and (in my opinion) most important feature in Ada is the ability to trivially create new types. So many languages require manually wrapping types. Better ones start to provide more magic to help automate it. But fundamentally none of them make user-defined types as a core component of the language. In Ada to create a new type it's just one simple line, and you automatically get full functionality of the base type while retaining incompatibility. The rest of the language and even the standard library is all designed around the idea of allowing the programmer to freely use these types.

You end up capturing so much more of the model that the program is using, and the compiler is able to check and ensure that the code is actually sensible according to that model. I find even the process of writing the types down helps expose flaws in the design I had in my head. Then once I start using it, it does a great job of catching when I start deviating from how I said everything should work.

Pretty much every other language I've ever looked at makes doing that sort of thing extremely painful. There is too much friction involved in detailing all of that, so nobody does. Then libraries are designed without it, which just increases the friction. Ada meanwhile makes it so easy to do that you feel bad not doing it, and you don't even gain much more than saving a handful of keypresses if you avoid it anyway.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#195
post #188

Earlier quoted context omitted.

As I said, I tried the FSF version at about 2018. Might be way better now, I don't know. My experience with gcc (C, not C++) for personal projects is exactly zero bugs. So, you see, experiences can differ ;-). When saying "you need the support contract" I mean getting the commercial compiler version. I think (theoretically?) AdaCore does not charge you for the compiler, but for support. And you only get access to the…

I mean, I was using FSF GNAT in 2018. And a few years before that, and some after it. I have a hard time imagining an experience even remotely described as unusable. I do wish AdaCore didn't leave the compiler situation so confusing. It's just enough to be a consistent distraction. Basically they all come from the same source. The GPL version gets a yearly release that, afaik is basically the commercial one (presumab…

"I have a hard time imagining an experience even remotely described as unusable."

Ok, so i should give FSF GNAT a try then. I always tried AdaCore's package. It's unfortunate that comp.lang.ada isn't available anymore. I think there were quite some not so fun bugs reported.

Anyhow. I had a look at https://www.adacore.com/gnatpro/comparison. What strikes me as odd is only support for x86 Windows/linux/MAC for the Community Edition. No ARM Linux (say Raspberry Pi)? That sure is not what it looks like, no?

I really don't want to pester you, but did you ever use Ada in a commercial setting and can you share your experience if so? I'm generally interested in Ada (i have a look at it every year or so), but the consensus on comp.lang.ada always was "for commercial usage you really should buy a commercial license (no matter the project, no matter from which company)".

Which more or less always meant AdaCore (some were suggesting Janus Ada, because of the moderate pricing) if you want an Ada compiler which supports the latest standard. Also, because AdaCore seems to be top dog in this area, with other vendors differing wildly in quality of compiler and libs.

I don't know if any of this is true, but those were the vibes from comp.lang.ada i received.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#196
post #195

Earlier quoted context omitted.

I mean, I was using FSF GNAT in 2018. And a few years before that, and some after it. I have a hard time imagining an experience even remotely described as unusable. I do wish AdaCore didn't leave the compiler situation so confusing. It's just enough to be a consistent distraction. Basically they all come from the same source. The GPL version gets a yearly release that, afaik is basically the commercial one (presumab…

"I have a hard time imagining an experience even remotely described as unusable." Ok, so i should give FSF GNAT a try then. I always tried AdaCore's package. It's unfortunate that comp.lang.ada isn't available anymore. I think there were quite some not so fun bugs reported. Anyhow. I had a look at https://www.adacore.com/gnatpro/comparison . What strikes me as odd is only support for x86 Windows/linux/MAC for the Com…

I haven't used Ada in a commercial setting, unfortunately. I was never that involved with comp.lang.ada so I can't really comment there. However I never really got that impression from freenode #ada. Based on what I heard there, I'd describe it more like "if you don't know that you need it, you don't need it." I also got the impression comp.lang.ada tended to be a bit more um... conservative, if you will. I'm not so surprised to hear they were more inclined to have a commercial license.

Personally speaking with my own experiences and what I saw on #ada I'd be comfortable going without a commercial license. I've only ever seen problems with somewhat odd situations, and I'm pretty sure all of them produced a bug box (compiler error message) so at least I was aware of the situation. And Ada often has multiple reasonable ways of doing something, so even if the odd/clever thing causes an error it's unlikely to be a blocker. Mostly it means I would have to put up with usage that's a little more not to my taste.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#197
post #195

Earlier quoted context omitted.

"I have a hard time imagining an experience even remotely described as unusable." Ok, so i should give FSF GNAT a try then. I always tried AdaCore's package. It's unfortunate that comp.lang.ada isn't available anymore. I think there were quite some not so fun bugs reported. Anyhow. I had a look at https://www.adacore.com/gnatpro/comparison . What strikes me as odd is only support for x86 Windows/linux/MAC for the Com…

I haven't used Ada in a commercial setting, unfortunately. I was never that involved with comp.lang.ada so I can't really comment there. However I never really got that impression from freenode #ada. Based on what I heard there, I'd describe it more like "if you don't know that you need it, you don't need it." I also got the impression comp.lang.ada tended to be a bit more um... conservative, if you will. I'm not so…

"I also got the impression comp.lang.ada tended to be a bit more um... conservative, if you will."

   Hehe, yes definitely. But considering the projects some of the participants worked on, i can understand why. For those projects you do need a specific mindset.
So, thanks for sharing your experience. I will try the FSF version. Maybe this is the path forward for my personal projects (which might end up commercial ;-) ).

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#198

It has to be said that Adacore is a French company, there is more to it than just a technical decision

AdaCore was formed by various individuals at New York University who were involved in the creation of GNAT, which was a DoD funded project. The company is still based in New York. Over the years they have expanded into various parts of Europe.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#199

I've never written in Ada, but I did come across m2os the other day: an Ada-based system for Arduino Uno microcontroller (and a couple of others) that features a simple scheduling policy. This is actually quite intriguing: a language that includes the concept of tasks at the language level, rather than trying to hammer in a bunch of macros or somesuch into C to achieve a similar result. It makes you wonder if Ada rea…

Ada is a really good system programming language, especially if you have to get very low level, where the language allows for very fine control over memory layout and for interfacing with hardware. All that _without_ sacrificing type safety. In addition, if you want to make your software even more bullet proof, you should consider the SPARK subset of Ada and statically prove the Absence of Runtime Errors, which includes memory safety. Furthermore, with SPARK you can prove various higher level properties of your software, thus reducing the number of unit tests needed.

Re: Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

#200

The first real programming task of my apprenticeship when I was 17 was porting a Boeing Ada avionics project to C. Looking back years later that just feels wrong.

yes, that is a big step backward. One of the details that people don't realize is that the Ada code probably had runtime checks inserted by the compiler to help catch issues. In addition, the Ada code most likely restricted the set of input values or prevented accidental mixing of different numerical values using its strong type system. When you convert to C, you lose all of that. If there is a code change down the road, you could have an error occur that might have been caught by the Ada compiler at compile time, or if not then by an Ada runtime check. Yes, testing has to be really good to minimize these cases, but we all know it's difficult and very time consuming to develop test for every possible combination. In addition, when you have to do code reviews, you have to worry about a much wider range of possible bad values that can be passed around which can screw up the results.
Post reply on HN