IMHO, Ada missed its chance to shine when it didn't have any satisfactory FLOSS build chain right at the time that paying for a compiler became a thing of the past.

I think you may be right, but it's disheartening that this essentially boils down to a failure of hype.

Ada may be a good language, and GNAT may be a fine Free and Open Source Ada compiler, but Ada isn't a new programming language. Software developers only chase shiny new things. Ada is held back by its beginnings as a niche language with expensive compilers, it doesn't matter that this hasn't been the case for decades now.

Don't undersell that programming is tribal, and any language that deviates too far from the C/C++ syntax (from the ALGOL mold, that is) will constantly be fighting against what people consider the "norm" and those preconceptions. The closer the language is targeted at something that C and C++ are still commonly the main choice for, the harder it will be to get some people to consider an alternative if it using different syntax or structure in any way.

I think one big stumbling block people had in adopting ADA (along with there not being a good open source toolchain for a long while as noted here) is that it just looks different to people that primarily use C and similar languages, and that puts some people off.

That's sad, and I would rather it not be true, but it's become increasingly obvious to me from how people treat numerous newer languages I've seen pop up over the years.

There are plenty of very successful languages that look nothing like the C family. I think the syntax of ADA has a different issue, which is that it- to me at least- evokes languages that are considered old fashioned or out of date like BASIC/Fortran/COBOL.

I'd be more than willing to give Ada a chance, but when I looked at code samples I definitely had to fight an automatic response of thinking it was something out of date based on how it looks.

> There are plenty of very successful languages that look nothing like the C family.

It's not that there aren't successful languages and have a different look and feel, it's that there's pushback against them when they are targeted towards the niches C and C++ are already strong in. Obviously many languages exist and many have become popular, but certain niches are more resistant than others and sometimes it's for non-rational reasons.

> I'd be more than willing to give Ada a chance, but when I looked at code samples I definitely had to fight an automatic response of thinking it was something out of date based on how it looks.

That's part, but not all, of what I'm talking about. The style C follows is damn old itself, sometimes predating the languages you're thinking of as out of date.

> it's disheartening that this essentially boils down to a failure of hype.

Maybe also, but not only. In contrast to Rust, Ada docs have been awful, and as long as you didn't get a commercial toolchain you had to play with some gimped version (and the really free version didn't come out until the language was 20+ years old), the build system was as “good” as C, people complain that Rust is verbose, but Ada was still a notch over, the memory model of Ada is a mere reflect of Rust's one, and (maybe I'm being subjective here) Rust's stdlib and philosophy is leagues over Ada's (Option, Iterator, closures, Result, ...).

Ada had the potential to be a Rust 30 years before, but it was never the goal of its owners.

> it's disheartening that this essentially boils down to a failure of hype.

That kind of thing happens; we're in a profession that is made up out of people.

Quiet frankly, they solve different problems. Ada includes a GC as part of the runtime and can still run into memory safety issues if you don't use the GC.

Rust has opt-in memory safety issues but outside of those, does not require a GC.

Rust does not have Ada's constraint system. In that way, rust is easier (and arguably less safe) to program.

Ada didn't get the same love as Rust for the same reason D goes pretty unloved. The problem systems engineers needed solved was memory safety without a GC. Neither D nor Ada solve that problem.

This is incorrect, Ada's spec leaves open the possibility for GC, but none is mandated or even used AFAIK. The GNAT runtime is non-GC.

Right, but (not counting extremely recent work that's directly inspired by Rust and therefore necessarily less mature than Rust's implementation) when you use Ada without a GC, you either have to avoid dynamic allocation or use Unchecked_Deallocation, which lives up to its name.

Static memory allocation is totally fine if the thing you're building is, like, a control system for a jumbo jet. You know exactly how many engines you have, how many wings you have, how many pilots you have, etc. Your autopilot has a fixed set of parameters: heading, speed, altitude, etc. You know exactly what tasks you're running: watch engine performance, watch the altimeter, watch cabin pressure, find the instrument landing system and line up with it, etc. If you have some new instrument to plug in, you get a new version of the flight control software, and you're certainly not plugging in new things mid-flight. Even if you aren't running all the tasks at once - e.g., you're usually not landing the plane - you want to guarantee you could turn on any of those tasks. You never want the possibility of running out of memory when you try to land, so you want to allocate memory for landing the plane at design time that's always reserved for landing the plane, and nobody would call that a "memory leak."

A general-purpose OS like Linux is different. You can create as many processes as you want. You can mount as many filesystems as you want, of various formats, whenever you want. You can plug in devices while the system is running. You can add drivers to a running kernel and remove them too. You can configure network connections, turn swap on and off, etc. Inbound network connections can show up at any time. So it needs dynamic allocation.

Ada is fantastic for problems like a flight computer. But it's a different sort of problem. For a general-purpose OS, you are allocating and freeing things in response to user input, and you want to make sure you neither leak memory nor use memory after it's been freed.

Rust is very good at solving that specific problem without the need for a GC. That's what people mean when they say "Rust doesn't use a GC."

Memory safety without a GC.

AFAIK short of SPARK:

* Ada has pointer arithmetic, you can overflow buffers or read out of bounds.

* Dynamic allocation is straight unsafe and unchecked (unless you have a GC, in which case… you have a GC), you can use-after-free and double-free if you copy pointers beforehand.

* Accessing uninitialised variables is not forbidden.

* You can dereference null pointers (though it should cause an exception so I guess that's memory-safe).

> * Ada has pointer arithmetic, you can overflow buffers or read out of bounds.

Not true. Arrays have bounds and those are checked. However, you can do arithmetic with the type ptrdiff_t of the package Interfaces.C.Pointers. You can also do an Ada.Unchecked_Conversion on a pointer that you get from a C function. Obviously that's unsafe.

> * Dynamic allocation is straight unsafe and unchecked

If allocation on the heap fails, it will raise a Storage_Error, but you can catch it. Also, the language has a lot of restrictions on when you may copy and store a pointer.

> * Accessing uninitialised variables is not forbidden.

True, but there are pragmas like Normalize_Scalars (to initialize them to invalid values) or Initialize_Scalars.

> * You can dereference null pointers

True, but dereferencing will raise an exception. Also you can define non-null pointers like this:

    type Foo_Ptr is not null access Foo;

or add a "not null" constraint to a nullable pointer type:

    procedure Bar (Value : not null Foo_Access);

Ada syntax is too verbose.

Ada deliberately places readability before writeability. It's interested in the maintainability of large mature programs, and isn't intended for rapid application development.

I don't have enough experience with Ada to comment on whether its verbose and keyword-heavy syntax succeeds in this goal.

Ancedotally, I agree with zerr's comment below. Its generally not the syntax/keywords that make code hard to read, or easy to maintain. If you're familiar with the language, you learned to parse those basically sub-consciously.

For me, its always the var/function names and comments that determine how readable a program is.

Code is not a prose. C-like syntax is much easier to read compared to Ada/Pascal's text blobs.

According to studies which we have none of right now.

So that's like... your opinion, man.

Besides, if the prose would have been preferable over symbols, we'd be writing e.g. "an unknown number of apples summed up with an unknown number of pears equals to one hundred entities" instead of "x + y = 100" in math classes :)

That's a caricature. We sometimes use words for summation, e.g. Python's sum and fsum functions. I do wonder though if people had to write like that before the development of modern mathematical syntax. Even the '=' symbol is relatively young. Wikipedia tells me it was invented in 1557.

SQL is another 'wordy' language. There are many, many things wrong with the SQL language, but I wouldn't say its wordiness is one of them.