> 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.

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.

> 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.

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).

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."

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

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.