Every time I see something on Ada, it seems like a really nice language. Easy to read, easy to write, performance seems to be there with C++, easy (?) to interface with C, multi-threading seems to be somewhat easy too...
So, what's the deal, where's the catch? Why people aren't jumping on it like they do with, I don't know, Rust?
I like Ada a lot, and I've been known to push it, only half-way kidding, on many occasions. However, there are a few things that make the language somewhat annoying to use, especially for someone who is accustomed other up-to-date languages (Python, C++11, Java, Scala, etc.). The obvious one is probably the verbose syntax, but really I don't mind it too terribly much (writing "function bah return integer is begin .... end blah" does get a little old though). Here's a list:
* No type inference. The lack of type inference means that I end up typing the names of types all over the place (or renaming them to be short, which doesn't really help the reader much).
* No lambdas or closures. I really want to be able use higher-order functions, but Ada makes that difficult.
* Extremely verbose generics. Ada has amazing support for generics, but there's so much overhead to use them (syntacticly) that I usually avoid them.
* Strange dispatch syntax. I personally like it, but it is strange to those more accustomed to C++ or Java, where methods are part of the class. In Ada, methods are declared as taking a "tagged" type as a parameter. Related to this, I really think Ada should support multiple dispatch (if you're going to have the strange syntax, why not?).
Actually, everything you've listed seems like a good fit for a C programmer (me) to give Ada a serious spin. Maybe not for a C++ programmer.
In the meantime, I've learned about the existence of "-fdump-ada-spec" for both gcc and g++. Apparently, g++ driver is preferred, even for C code. How cool is that? Automatic thin wrappers for your existing code with nothing more than a 'g++ -c -fdump-ada-spec -C super_awesome_code.h'. I've just tried it on a somewhat large-ish codebase which has a single .h as an entry point and it created a bunch of .ads thin wrappers with only two unsupported macros (one doesn't matter and the other is for dllimport/export shit). If this works, it might be an easy ticket into Ada adventures for a C programmer.
I'm pretty familiar with most of these issues, except for the one about verbose generics. What do you find so verbose about them?
To my thinking they aren't much more verbose than C++ templates. They end up being a short little section above the place they are used. However I don't really feel like it's a verbose language in the first place (even if there are a few more characters around) so perhaps I'm just missing something entirely.
Ada is like Smalltalk or Lisp at this point. It's not new and shiny. It's not being marketed. It's seen as outdated, or even extinct (how many people know an Ada developer or project)? Like it or not, people bandwagon technologies. Not to say anything against Rust, Go, etc. But how many people who have jumped on one of those bandwagons did so after examining Ada, and found it wanting in comparison, do you suppose?
There's also the expectation that a more modern language will have modern tooling people today need, and community support easy to find (if it's caught on).
You see Ada used in legacy code bases in aerospace and defense. A big problem, at least at an ex employer of mine, is that no young engineers have a desire to learn Ada. It completely pigeonholds you to the aerospace/defense industry's legacy systems.
That's been true for at least a quarter century, since I was a young engineer hearing Ada mentioned as another one of those fusty old legacy languages like FORTRAN or COBOL. Even if I'd felt any interest in trying it out, I had no access to any Ada compiler.
Perhaps you didn't have access to an ADA compiler 25 years ago, but GNAT has been free and open source for about 20 years and part of GCC for more than 15. Of course, 20 years ago, ADA was already 15 years old, so no surprise that when it became accessible it was already branded fusty.
Even back in the 1980s, ada had a "stodgy government bondage & discipline language" reputation. At least among the hacker set, who back then was all about bit-banging the machine.
I'd speculate that ada never received the big commercial push, like Sun Java received. There were no salesreps talking up ada on the golf-course to CIOs, and there weren't marketing people planting 'Ada is great' stories in the popular press. It always had "the pentagon made me use it" aura around it.
I think this is akin to statements when companies say they have a shortage of developers. Of course they do when they offer no good incentives to join. Offer (above) market salaries and young people will flock to Ada.
It may be wrong, but from occasionally attending Ads talks at FOSDEM, I got the idea that at least in Europe in what concerns high integrity systems, Ada's has be slowly increasing.
Also quite a few European universities do seem to teach it nowadays.
I'd expect someone who knows VHDL could get up to speed on Ada pretty quickly. VHDL is a widely used Hardware Description language, which was derived from Ada.
Rust demonstrably gives you stronger static guarantees than Ada, which, just like C++, is a lot larger than C, for relatively little benefit in terms of safety.
Rust can give stronger static guarantees in simpler instances. When it comes to more complex cases, neither language can guarantee much. Ada however has better mechanisms for handling them safely. For example, you can specify a particular allocator for individual types rather than relying on each allocation to use the custom allocator.
If you're outside the realm of the Rust borrow checker and want to use an arena to keep the memory side of things simple and safe, it's much easier to do properly in Ada.
Ada is also significantly safer than C. Between the much stronger type system, memory safety facilities, bounds checking, non-nullable pointer types, generics, contracts etc. it's clearly a much safer option than C.
> For example, you can specify a particular allocator for individual types rather than relying on each allocation to use the custom allocator.
Having a 1-to-1 correspondence between types and allocators screams of lack of separation of concerns. In any case...
> If you're outside the realm of the Rust borrow checker and want to use an arena to keep the memory side of things simple and safe, it's much easier to do properly in Ada.
The article literally says: “Tasks are awesome, but sometimes they're not quite what you want --- particularly as there's no protection against two tasks modifying the same variable at the same time.”
So much for memory safety.
> bounds checking
Implementable as a library feature. For example, in Standard ML:
signature BOUNDS =
sig
val minBound : int
val maxBound : int
end
(* INTEGER and Overflow are in the Basis Library *)
functor BoundsChecked (include BOUNDS) :> INTEGER =
struct
type int = int
fun toInt x = x
fun fromInt x =
if x < minBound orelse x > maxBound
then raise Overflow else x
val op+ = fromInt o op+
val op- = fromInt o op-
val op* = fromInt o op*
(* rest of implementation... *)
end
There is no need to bloat the core language.
> non-nullable pointer types
In an unusable way.
> generics
Parametric polymorphism buys you non-repetition, not safety.
> contracts
Contracts don't buy you safety. Your code will just crash at more predictable places when a contract assertion fails. But it will still crash. Hard.
> Having a 1-to-1 correspondence between types and allocators screams of lack of separation of concerns. In any case...
It's a 1-to-1 correspondence between an access type (aka pointer) and an allocator. There isn't an issue with separation of concerns.
> Arenas can be given safe interfaces in Rust just fine
I never said they couldn't. I said, they require the arena allocator to be used explicitly for each and every allocation. So if you screw that up, it's a problem.
> The article literally says: “Tasks are awesome, but sometimes they're not quite what you want --- particularly as there's no protection against two tasks modifying the same variable at the same time.”
And if you bothered to read another few sentences, you would see the article mention controlled types. These are types that exist to be task-safe. It's entirely safe.
> <bounds checking> Implementable as a library feature.
Which makes it more difficult or impossible (depending on other language features) to detect such errors at compile time. It's also much harder or impossible to optimize away the checks when possible. And finally being a separate library means it's not part of the core language. You might call that bloat, I call it good design that not only requires safety but fosters an environment that encourages safety. You can have all the best most safe features in the world, but if they are hidden off in a library then programmers must explicitly reach for them and by default start off playing around in unsafe ways. It becomes a cultural thing.
> (non-nullable pointer types)In an unusable way.
What? Care to expand? I've used them before, so they are usable in some sense at least...
> Parametric polymorphism buys you non-repetition, not safety.
Non-repetition buys you a single place to screw up, rather than many.
> Contracts don't buy you safety. Your code will just crash at more predictable places when a contract assertion fails. But it will still crash. Hard. Static analysis buys you safety.
Where possible Ada contracts are checked statically. Contracts that are checked at run-time do buy you safety too, though. Not in a given build, but unless you are in the habit of shipping as soon as you get a successful compile, having crashes occur as soon as there is a problem is a wonderful way of being able to quickly identify not only that a problem exists, but what the problem is. In terms of actual software development, it very much helps with producing correct software.
It's relatively easy to create a type which can't be created at all by functions outside the module it's defined in - add any private member. Then that module is in control of how it's created, and can set any restriction you like. This pattern is regularly used in Rust to ensure that types are always initialised correctly.
Sure, you can do things like that too in Ada. To some degree that might make sense sometimes, but having the option of an equally safe type that's used in a "normal" fashion, rather than something that has to go through the proper library interface has some advantages as well.
In my opinion, Rust traded in too much readability for conciseness and made a number of dubious syntax choices.
Don't get me wrong, I'm just talking about personal preferences and I'm planning to use Rust in future projects. It's a fine language. It just tries too much to please programmers from other languages...
I tried to use Ada for some numerical code I was developing a few years ago (see this old blog post of mine: http://ziotom78.blogspot.it/2012/09/discovering-ada.html). The language is fantastic, and the type system is perfect for describing physical quantities which can only assume values within well-specified ranges.
However, what made me put aside Ada is the lack of scientific libraries. Nothing similar to NumPy/SciPy/LAPACK/FFTW/GSL/ATLAS... exists, and writing nontrivial bindings to C libraries is extenuating. The problem is not to write thin bindings: this is almost immediate, as the post shows. But if you want to take advantage of Ada's features, you want thick bindings. And this is a long and complex process.
I was able to create bindings to a few CFITSIO functions (https://github.com/ziotom78/adafits), and it took more than expected. When I realized that even completing this set of bindings would have been just a small step towards the kind of full scientific stack I need for my daily job (I'm an astrophysicist), I gave up with Ada.
I think the same situation applies for other fields than astrophysics. How many Ada bindings to commonly used libraries (e.g., ZeroMQ, dbus, bzip2, libjpeg, libunicode, Qt, OpenGL, glib, etc.) exist today?
It seems the real technical issues are surfacing as the posts flow in. There are two. Primary being that burden/control is in one company's hands and the other being lack of (thick) wrappers for C libraries. That other issue is common among less popular languages. First one is concerning, not much because of potential malevolence of Ada core, but more that they seem to do a lot of work and that can present itself as a bottleneck.
On a sidenote, you're an astrophysicist? How awesome is that?! I'm in TV and Film, and I wanted to meet/know one who I can pester here and there with questions/collab for an SF script development I had in mind which I would like to present in 'accurate' way.
Agreed. At the end I turned to Python + Fortran (via the awesome f2py) for almost everything, although using two languages is far from ideal. It confuses students which hardly know just one of them, plus there is the cognitive burden of using two different sets of conventions (e.g., zero-based vs one-based array indices) and models of computation.
I don't know how much help I could give you regarding your script, but I would be happy to help. Feel free to contact me, my email is maurizio dot tomasi at outlook dot com.
Interfacing with C is actually a lot of work. Not that it is not possible, but if you write a light wrapper, you end up with all the low-levelness that makes up C.
If you want to use a C library „the Ada way“, you need to wrap almost every C function with an Ada function that transforms C pointers into Ada arrays (remember, [] in C is just a pointer with no dope), C defines into Ada enumerations, C function pointers to Ada subprogramm access types and so on.
This amounts to a lot of work. For example, my OpenGL Ada wrapper is roughly 10,000 lines of code. But it does do extension loading and resource management automatically (in contrast with the raw C API) and all defines have been translated to enum values so you can call functions only with values they can handle.
This is totally true. Interfacing with other languages is important.
The operating system is in C, so to use all the operating system provides, the networking, shared memory, IPC you need a wrappers.
If your sharing data with C code, you need to make sure you ada records match your C Structs so they align correctly. Ada was remarkably good at letting you set where things went in memory for each record.
Part of a past job was to write and maintain ada wrappers for a large Ada project.
Not long ago I found articles about ADA Generics and low level code (I was looking for swappable network stack in theory), it was pretty interesting. I can't find the bookmarks for now.
- having to write separate interface files (analogous to header files in C)
- only one relevant compiler vendor; somewhat bad history with GNAT not supporting all the features the commercial AdaCore tooling supports. AdaCore has IMO been instrumental in holding back adoption of Ada, although they probably see themselves as evangelists.
- no metaprogramming
- the way generics work is a bit peculiar: it's less powerful than C++ templates (but a bit easier to learn) and slightly more powerful than Java/C# generics, but I find it to be a weird middle ground. I implemented some generic graph traversal algorithms via generics, but it felt like jumping through hoops (although once tackled, it was very robust and extensible).
As for me, Ada is an excellent language for safety applications but too much under control of a single company.
GNAT is open source, that's fine. However, despite this fact it is almost impossible for someone to write a new Ada compiler, or a transpiler from a modern syntax to classical Ada because there is no complete BNF grammar out there. I honestly planned to write such such a transpiler but it didn't work out because I lacked a fully specified BNF grammar. I complained about that in an Ada forum, and the insiders there confirmed that there actually is no downloadable BNF. There is just a BNF for Ada 95 which is pretty outdated.
So, if I wanted to get the full BNF for Ada 2012+ I would have to dive into all the Ada Reference Manual and Rationals to scratch a suitable grammar together. That's way too much effort for me.
I get the impression most people jumping into Rust, go into computers after C and C++ became the widespread tools for systems programming, which makes them unaware that there was a time when safer systems programming languages did exist.
So they got biased in that regard.
Second Ada compilers used to only be available in enterprise prices, and they still are.
GNAT is the only one available as open source, the ones from PTC (they bought Aonix and Atego ones), Green Hills and a few surviving others are still sold by having to call their sales guys.
Finally, Rust does offer more safety features over Ada, like the lifetime management or type inference.
Still, it would be nice to see more Ada love in the industry.
I'm using Ada for time-critical code in my hobby projects. In my opinion, there are four major catches:
* Long learning curve: The syntax is unusual in that it is specifically defined for every construct of the language. That makes the learning curve long, because you need to grasp the possibilities for every syntactic construct separately and there is some multiple uses of keywords like "with". Generally, conceptual simplicity is not a strength of Ada.
* String handling: In an attempt to please everyone, Ada provides fixed-length strings, bounded-length strings, unlimited length strings with byte-sized chars, wide chars, and wide wide chars and you have to convert between these representations all the time. Nevertheless, it only supports UCS encoding, not UTF, in the core language. So to e.g. use UTF8 strings, you either have to abuse ordinary byte-size char strings, which is a type error, or use an external package plus all the conversions to and from the internal format. It's a constant pain in the ass and source of non-portability, and they should have included full support for UTF8 and/or UTF32 in the recent standard.
* Too strict aliasing rules: Apparently to keep the static compiler checks simple, Ada's rules for pointers (aka aliases) are sometimes too strict, i.e., you may sometimes not be able to use pointers to procedures and heap-allocated objects even when it is provable that they cannot dangle. This can create major problems or force you to do unsafe conversions or overlays, if you don't design your application carefully. Arguably, there are only rare cases in which you should use pointers and you generally don't need them very often in Ada. But it can be a tumbling stone for people coming from C or C++.
* Licensing & vendor lock-in: If you install AdaCore's version, your programs become GPL! If you don't like that, you need to install FSF's version, which does not come with some essential libraries from AdaCore that are also GPL. However, evern FSF's version is only mGPL, not LGPL, meaning it is GPL with a runtime exception. Generally speaking, license confusions have kept many people from using Ada. Moreover, the only really modern compiler comes from AdaCore (who contribute GNAT to gcc), other compilers only support Ada95 and are prohibitively expensive anyway. So there is also a certain vendor lock-in, and e.g. fear that AdaCore might stop contributing to the mGPL version. That's a big issue for anyone who would like to use Ada for business without buying expensive licenses from AdaCore.
Basically, AdaCore is a dubious player, not a role model of a successful open source software company, as it is sometimes portrayed.
Other than the above, Ada is a fantastic language. Once your code compiles, it nearly always works, and you will be able to understand it years later even if it is undocumented. Ada really is self-documenting and fast, that's why I use it.
Edit: Forgot one thing. It's also a disadvantage that no current Ada implementation has a GC (although a GC is compatible with the standard). Since it has become trendy to bash GCs and advocate manual memory management for mostly unsound reasons anyway, the point didn't make it in the list above.
However, evern FSF's version is only mGPL, not LGPL, meaning it is GPL with a runtime exception.
Hmm, how does that demonstrate itself in practice? It shouldn't matter for your app, right? With FSF version you can(?) compile and distribute your stuff. Like with 'normal' gcc/glibc. How about static? Licenses usually throw me off since they get so confusing.
It seems like it's a story similar to Lisp and Franz/Allegro CL. Lisp got better with SBCL supporting Windows later on.
I agree that Ada's string handling was terrible. More than terrible in fact.
>If you install AdaCore's version, your programs become GPL!
You sure about that? I worked at a company moving from Old Unix to Linux and were going to move to AdaCore compliers. This was a company that wanted to make sure when we downloaded software it went through a legal dept to check the licencing, and having the companies code released GPL would have been a non-starter. This was 10+ years ago though..
They were contemplating purchasing a license I know. I left before anything happened.
Keep in mind they were paying a fortune for support for another ada compiler (Rational APEX) on obsolete hardware (Solaris/ HPUX). I suspect they were evaluating if it was cheaper than migrating a huge codebase to another language.
Migrating platforms can be a pain in the endian.
It doesn't have that novelty factor. One could ask similar questions about D, which has for a long time positioned itself as a friendlier C++, but hasn't had any of the buzz that Rust or Go or Nim, etc have garnered.
A bit tangential, but I did (heavily so) jumped into D before D2 and kind of got burned with that. I married D1 which was more in-line with "a better C" and then everyone decided D2 was the way to go, which was more "a better C++". It was to be expected though since language was in flux a lot at the time.
Ada is a stable language though. I get what goatlover and Avshalom here are talking about here. That it's not fashionable (anymore). If we remove ourselves from that, are there any specific technical reasons why Ada hasn't been picked up by, let's say, C++ programmers? That is, audience that needs performance, yet also a nicer and safer language.
With Lisp(s) there was a long period of basically having to pay for a good implementation and runtime deployments to Franz for Allegro if you wanted to do something well on desktop. I recall only Nichimen with Mirai and Nendo doing it, and it was fabulous. Makes you think about what would happen if tooling was free at the time, or at least more affordable.
From everything I've seen, so far, Ada seems to be technically ready language to do game development, where probably most of language-curious crowd lives these days. I'm not sure about mobile support though (gcc on Android or whatever it is on iOS).
Every now and then I take a week of spare/hobby time and endeavour into new and weird technical spaces. Maybe, my next
one will be in Ada space.
Many C++ developers are former "type safe language fans" that is the tribe you see on the corner discussing how to use strings, vectors, class enums, shared pointers, class abstractions for IO ports...
But it is hard to justify management to go out and buy Ada compilers, with tooling that isn't on par with C++ ones.
Also on the embedded markets you still have company selling plain C compilers or when they sell C++ compilers it is still C++03. Those guys will hardly invest to building an Ada one.
For game developers, their culture is a bit different.
They only change language when forced by the OS and SDK vendors to do so.
That is how they moved from Assembly into C/Pascal, then from those into C++.
Lisp on Windows has a long tradition, but all useful implementations with platform integration and good GUI support for it were and still are commercial.
Corman CL. Cheap. Native. Abandoned and now open source / free.
Golden Common Lisp. mid-price, lots of functionality. No longer competitive.
Procyon CL. Expensive. Bought by Franz and taken from the market and used to develop a first Allegro CL for Windows offering.
LispWorks. Expensive.
Allegro CL: Expensive. Lots of functionality. Nowadays a merge of the former Windows and Unix versions.
There are free ones like Clozure CL, GCL, SBCL. But most of them lack platform integration.
I didn't know Nendo was C++. Somehow I thought since Mirai was Allegro that Nendo was also. TIL! Mirai was so ahead of its time, and I remember people were boasting Lisp had a lot to do with it (small team, big features and lots of them!). Of course, team was amazing - that was the primary reason.
If you look at CL Windows applications, they are either written in a custom Common Lisp implementation or Allegro CL / LispWorks.
Free software / open source Lisp has never supported Windows very well. Most of the time the Lisp was running without much integration and very little support for the Microsoft eco-system. Companies tried to target the market of Windows users. Open source / free software Lisp developers were never particular interested in Windows for their own use
I wouldn't recommend Ada for game development. First of all, the added safety is overkill for games. Second, you need to create bindings to libraries, and as we all know, C++ does not have a well-defined library interface to the outside world. You'll end up writing tons of fragile glue code, and still get all the crashes. ;) Third, mobile support and general portability is abysmal.
i think d and ada check off a lot of the same boxes. d seems to have gone the route the article mentioned at the end:
> Personally, I think that the original Ada designers wanted a garbage collector --- a relaxed-rules Ada with closures, inline maps, the ability to have range<> arrays in structures, variable-length strings etc would be totally epic.
and adds "modern conveniences" like compile-time metaprogramming.
It's kind of died down, but maybe a year ago it seemed to be pretty buzz-worthy. It was always third behind the other two, but I definitely remember when there were a good smattering of Nimrod posts on the front page here.
> There’s a generic function in the standard library called `Ada.Unchecked_Deallocation`, which frees memory to the heap.
A systems language without a safe resource finalization story is simply an unsafe language. This isn’t some fringe use case. Finalizing resources is a common operation in systems programming.
Other “benefits” of Ada just consist in bloating the core language with stuff that can be reasonably done in libraries: bounds checking (in ML, this is just a functor that produces an abstract type of bounds-checked integers), concurrency abstractions (as Rust has shown), etc.
For safe resource finalization, Ada provides `Ada.Finalization.Controlled`. This enables you to implement RAII, smart pointers, and other ways of safe finalization. `Ada.Unchecked_Deallocation` is just the bare-metal tool you can implement more intelligent finalization with (because in the end, someone needs to deallocate the memory).
It's a shame there wasn't more information on the tools Ada provides for concurrency - I haven't seen another language which gives you as much flexibility and power to write safe concurrent code. It's much more heavy weight than some other languages in some ways, but gives you very strong guarantees you don't get elsewhere.
It also would've been nice to talk a bit about some of the features which make it particularly well suited for embedded systems:
* things like the ravenscare profile which give you a safe subset of the language using statically allocated never terminating threads
* the ability to select the scheduling algorithm (including ones with task priorities which are used to avoid the possibility of deadlocks completely - see the priority ceiling protocol for more details)
* the ability to address specific memory locations being built into the language, not just casting ints to pointers like you would in C
* full control over how elements on records are laid out, including endianness, this is essential with the previous feature when you're dealing with memory mapped IO registers for controlling hardware
For anyone who's had to write code to interface with hardware on micro controllers, they're probably wetting themselves with excitement by now, doing this in C relies on the compiler doing what you think it will, which there's no guarantee of because the ability to use many of the features is implementation defined, if defined at all.
This really makes me want to try Ada, if I could find a good fit for its low-level features (game development, maybe?)
The biggest thing that would make it annoying to write in is the verbose syntax--it's like the worst of Java, VB, and Standard ML. And yet, that same verbosity makes it kind of nice to read.
I think there's an inherent friction between "write-friendly" and "read-friendly" languages. It would be nice to have a language with a few different "dialects" (the way Ruby often has several equivalent ways to write certain constructs), such that a programmer could write the initial code in an extremely terse language, then run a formatter and get back a beautifully-formatted, much more verbose form of the same code.
Verbosity leaves me on the edge as well. But then I look at the promise of what Ada brings. It would mean trading in a bit more writing time for a possibility of a lot less debugging time.
Anecdotally, it's vastly reduced debugging time in my own personal projects. My most notable problems have all turned out to be the result of things like using the wrong input, or misunderstanding some external spec. At first it was actually a little unnerving that things weren't breaking, but with time I've come to expect that. I came from C++, where I always joked that if things appeared to work correctly the first time around something serious was broken.
It's not free though. You do end up spending more time getting the compiler to actually accept your code. With time I've gotten much better at this, although at first it could be quite a fight. But a compiler error is so much nicer than a bug, so I do think it's very worth it.
And when it comes to coding, how long it takes to type is pretty irrelevant as long as you can type half decently. Typing the code is really the easiest part.
I haven't learned Ada yet, but I've heard praise and eulogies from HN a few times it has been mentioned in recent years.
At first pass, it appears to have a lot of unnecessary keywords, and the semicolon terminator (at first pass) seems arbitrarily required.
Is it really that great of a language? What does it provide that FORTRAN, C, and/or Julia don't provide in terms of speed, or Python in terms of readability?
The advantage of Ada is that it's meant to be an incredibly safe language.
That's why blocks have to end with the block type (e.g. if...end if)
This is to ensure that you haven't accidentally nested things wrong. It also has runtime bounds checking for arrays, ranged variables, no multi-line comments, safer pointer handling etc.
At the time, it was definitely one of the safest languages to use.
Fortran is a real pain to read or write, and is designed more scientific computing than applications. C is terribly unsafe (hence why buffer overflows are the most common security vulnerability).
Quick note others may find useful. I found this offputting: the idiomatic mixture of upper/lower case and underscores in the syntax. Unnecessary cognitive overload. I've just done a quick test with current gnat and this works: you can just write everything in lower-case.
I'm just going through the motions. GCC has FSF GNAT which I wan't on macOS, but in order to compile gcc with ada support you need to have GNAT already.
So, what I'm doing now is: download GPL GNAT from Ada Core here: http://libre.adacore.com/download/ and build your gcc, as usual, with ada support from that. Then you can use FSF GNAT gcc. You can even compile again with FSF gcc to make it double sure it's working.
Apparently, FSF GNAT version is what you want in order to make commercial software since it has a runtime license, which Ada Core version doesn't. You would have to pay for Pro version. Someone correct me if I'm wrong.
The language is pretty old. I'm not sure it needs a huge amount of extra features. They added full OO support awhile back, although its probably not necessary for a lot of embedded projects. There's a company (Ada Core I think) that keeps their products up to date.
Indeed, that company is Ada Core, and their pricing page tells you everything you need to know about why you're not using Ada:
"""
All of our products are available as annual subscriptions... For general inquiries regarding our products and solutions or to learn how you can apply for an evaluation, please contact sales@adacore.com.
Use the following form to receive a price quote. Please fill it out as completely as possible so we can provide you with the most accurate pricing information.
""" -- http://www.adacore.com/gnatpro/pricing
In other words, standard Enterprise Pricing: "if you have to ask, you can't afford it."
the big thing for 2012 was adding more design by contract support and (as a consequence) added limited support for control structures to be expressions instead of statements (which I expect will slowly expand in the future).
So, what's the deal, where's the catch? Why people aren't jumping on it like they do with, I don't know, Rust?