The literally verbose syntax contributes to its unpopularity as well. It is extremely hard to skim/read and comprehend prose-like Ada code.

Wouldn't Rust's symbol heavy syntax contribute the same?

I think that since a significant portion of Rust developers come from a C++ background, and C++ uses basically the same set of symbols, it's not a huge barrier to adoption

Rust actually has a bunch of oddities, to the point they test them [0].

[0] https://github.com/rust-lang/rust/blob/master/tests/ui/weird...

There's really only one sigil in there that isn't in C++ (the ' single-quote to name lifetimes and labels). And it's missing several ambiguities that plague older C++ grammars (i.e. is >> a greater than, or closing two template expressions?)

> (i.e. is >> a greater than, or closing two template expressions?)

I thought it was a pointer-dereference signifier(, or maybe an object-string-stream thingy)? If you mean C++, that is.

I like Ada, but I tend to agree. "End Something_Somethig_Something" is really a mouthful (compared to "}"). And programmers are superficial like that. Ada wouldn't be the first decent language being dismissed for inconsequential aspects like this one.

Context free curly braces in deeply nested code make me crazy. Labels to match up with the open symbol would be super helpful.

My company’s style guide requires them on closing braces for namespaces.

Let me say that I do agree with you.

However I’d add that this job could easily be done by the IDE. For a reason that I fail to grasp, after being around for multiple decades, IDEs are still incredibly bad at presenting useful information on the code. Apart from coloration and more recently type hints, there never have been any real innovation in just helping reading code structure. For some reason we are still stuck with a tree of files besides some glorified text editor.

Interestingly, we have made incredible progress into code comprehension. We have incredibly mature ast parsers, lsp servers, … our IDEs know everything about our code structure but we still fail to make anything else with that data than autocompletion and doc popups.

It’s called “sticky scroll” in VSCode and Visual Studio [1]. It pins the opening line of a scope to the top when it scrolls out of view and it does it multiple levels deep so you can see the class, function definition, conditionals, etc at the top of the source file when browsing deeply nested code.

[1] https://learn.microsoft.com/en-us/visualstudio/ide/editor-st...

Okay that’s cool :)

There is some great work being done here - I'm watching GToolkit advances, and while I don't fully buy the "moldable" hype, the UX of reading and writing code in GT feels like sci-fi sometimes.

If you can't see the other end of a curly brace inside a function, I'm pretty tempted to say you're doing too much in one spot.

Extracting sequences of statements into a function sometimes improves readability, when those sequences do together some recognizable operation, but other times such an extraction worsens a lot the readability, because now you need to also open other pages to see what the program really does, when the statements in a sequence are not really related.

Even in programs optimally written for readability it is frequent to have iterations or selection statements much bigger than a page, especially where the coding rules enforce a small length for program lines, e.g. 80 characters.

In languages that follow Algol 60, like Pascal, C, C++ and so on, which have a single kind of statement brackets, it is frequently needed to add comments on the final braces or "end", to avoid confusions when reading the program.

This is much more cumbersome than in the languages that follow Algol 68, e.g. Ada and bash, where there are several distinct pairs of statement brackets.

In real life you’ll have to deal mostly with code you haven’t wrote yourself.

I do occasionally have a long switch statement that doesn't lend itself to be broken up. If all the branches are simple and operate on the same conceptual level, breaking them out into separate functions that wouldn't be useful anywhere else doesn't make sense to me.

But it's definitely not a frequent enough occurrance to merit replacing closing braces with lengthy names that need to be kept in sync with their opening counterpart.

Agreed but it’s not always my own code I am reading.

So, this is a problem with using good editors. I don't know if VSCode or any similar editors have the way to select current block / current function, but in Emacs (and mostly likely Vi(m)) world this is just part of knowing the ropes. So, giving extra emphasis to the end of the function (or block) is completely unnecessary, it just reduces entropy.

Other problems with this: one of the ways to navigate the code is by searching for the function (procedure) name. Now you have double the number of matches.

Also, when I find code with comments that add labels like "end of xxx", I automatically delete all of these. It doesn't help me at all, and only makes searches in the code more difficult. Even the bad editors like VSCode probably have the functionality to jump to matching delimiter, which would easily reveal the name of the block you are working with.

And your company guidelines... oh, it should be fun when someone renames a namespace, but forgets to update the comments. At least, in Ada it's guaranteed that the end and the beginning will match. Also, sometimes I prefer not to invoke any kind of automatic refactoring, but rather rename a function and see what other code breaks, to quickly find dependencies. It's really annoying that this renaming must happen twice.

Pretty sure Java in vscode and android studio places block names after }'s because it's hard to read otherwise.

End names are optional in Ada, so "fixing" that is just a style guide away. Meanwhile, Scala 3 added named `end` to help with long blocks on its indentation syntax.

Like in all such discussions: the problem isn't with what you write, but with what you read. There are tons of Ada code that's already written like that. So, future changes to the style guide aren't going to do much. Also, nobody's changing that anyways.

Philosophically this is a fair point but practically it is not. Eventually any programmer will start relying more and more on tools to help with skim/read/comprehend code bases, no matter the language. There's a reason that every text editor and IDE used for programming includes helpers to find subroutine calls, jump to matching symbol (curly braces, closing parenthesis, end statement, or tab-depth indicator), etc, etc. No language is so "easy to skim/read and comprehend" that you'd be happy with a realistically significant code base and only the navigation keys on your keyboard.

There's a very fine line between nice language syntax and ease of use via tools you use to interact with the language (with APL-influenced languages being the only exception I can think of, but even there I've heard of programmers having physical key map symbols overlaid on keyboards).

I got used to it after writing a lot of complex SQL. I even developed a preference for uppercase keywords.

For me it's the other way around, I can skim a program written in Ada and figure out what it's doing almost the immediately because it is highly structured and enforces correctness with no ambiguity through its syntax.

I can't really do the same for rust which tends to lend itself into a more confusing format.

It was considered verbose years ago but now days it is IMHO better than messy C++ templates or Rust syntax.

About two years ago, I was able to dive into the Ada reference manual formatter which has initial commit of March 2000 and is about 45k lines of code, and add MDX output pretty easily.

Other languages focus on terseness and expressiveness. Ada expresses a bunch of constraints directly and forces you to do things in organized ways (e.g. use namespaces appropriately).

Steve Klabnik (of Rust fame) wrote a (very generous IMO) article about Ada, interesting comparison: https://steveklabnik.com/writing/learning-ada/

I'm a bit disappointed that we've ended up with Rust in the kernel but not Ada. The kernel relies on GCC and there's already an Ada compiler in GCC, so it wouldn't require adding another compiler as a build requirement like Rust does.

There's a couple of major advantages that Ada could have in the Linux over Rust for safe drivers:

1. Having the option to use SPARK for fully verified code provides a superset of the correctness guarantees provided by Rust. As mentioned in the parent comment, Rust focuses purely on memory safety whereas SPARK can provide partial or complete verification of functional correctness. Even without writing any contracts, just preventing things like arithmetic overflows is incredibly useful.

2. Representation clauses almost entirely eliminate the need for the error-prone manual (de-)serialisation that's littered all over Linux driver code: https://www.adaic.org/resources/add_content/standards/22rm/h...

> 2. Representation clauses almost entirely eliminate the need for the error-prone manual (de-)serialisation that's littered all over Linux driver code:

Do representation clauses let you specify endianess? From a quick glance at that link it didn't appear so. I would imagine that invalidates most use cases for them.

You can specify endianness, but only over the entire record, not an individual field. The way it works is a little complicated: https://www.adacore.com/gems/gem-140-bridging-the-endianness...

Interesting, thank you. I think per-record is probably good enough for most applications, and less verbose than per-member. But it's not part of the language (that page calls it "implementation specific") and quite recent (that page is undated but references Ada 2012 so must be since then). It wouldn't have helped the Ada project I'm working on, which had an endianess crisis with serialisation a few decades ago.

Ada 95 added bit ordering.

https://www.adaic.org/resources/add_content/standards/95rat/...

https://www.adaic.org/resources/add_content/standards/95lrm/...

rust is in the kernel to attract the young developers, which ada does not.

GetIntoGamedev is not old, he's in his 20's. The issue is, is that people are not prepared to trying something if it doesn't look like C or C++.

But he's one. See how many people are jumping on the rust bandwagon…

> I'm a bit disappointed that we've ended up with Rust in the kernel but not Ada.

Why? Do you program in Ada or Coq?

People can't be bothered to track lifetimes, what makes you think they are ready to track pre/post-conditions, invariants and do it efficiently and thoroughly.

Having the option there is good, even if not everyone uses it. The same thing applies to Rust.

For Rust and Ada in Kernel they need to be accepted by kernel maintainers.

And seeing they can't stand Rust, when its constraints are much weaker than say Ada.Spark what chances does it have?

To paraphrase some computer science guru: The cyclical nature of programming languages is all to blame on collective programmers. Rather than being guided by mathematic rigour, they are guided by a fashion sense.

Agreed. It would also alleviate the maintenance issue as Ada was designed to reduce software costs. Realistically the obly way this will have any chance is if a few developers were funded full time to work on it. There seemed to be a few full time devs pushing Rust support and some drivers before it was taken seriously. Honestly Ada is the best language that I have seen for drivers and for network stacks or for registers received as bytes. Linux is missing out.

>ended up with Rust in the kernel but not Ada

Linus hated Ada. I suspect he doesn't exactly like Rust either but the Tribe is just too strong within Linux.

Do you have a source for that? I've found his remarks on Pascal and C++ but not Ada.

Linus' opinion on Ada (vs Rust):

> We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.

https://www.infoworld.com/article/2247741/linux-at-25-linus-...

For what it's worth, many Rust developers (including myself) are also Ada fans.

Note that ranged types, decimal types, etc. can fairly easily be emulated in Rust, with what I find is a clearer error mechanism.

SPARK is, of course, extremely cool :) There are several ways to work with theorem provers and/or model checkers in Rust, but nothing as nicely integrated as SPARK so far.

I would quibble with the "fairly easily" part. It will likely become possible to make them as ergonomic as the Ada variety if Rust's const generic and constant evaluation facilities are extended far enough, but this would also open up the can of worms of essentially giving Rust the full capabilities of a dependently-typed language (at least in its compile-time subset), which Rust's dev community may not necessarily be OK with.

I'll grant you that Rust is not nearly as ergonomic as Ada in this domain, but doing it manually is fairly easy. Turning it into a library is a bit more complicated - these days, I'd do it with macros. Of course, making sure that the compiler knows about it for optimization purposes would require lots of const generic.

The real benefit of Adas typing is that it is so easy to utilise often preventing logic errors.

And this is definitely a strong benefit.

The benefit of Rust's typing is that (in the absence of `unsafe` or bugs in the compiler or stdlib), it's a simple theorem prover. Much less powerful than the theorem provers you can use with SPARK, but it's a start :)

Ideally, Rust would start adopting excellent features like Ada's SPARK, and vice-versa Ada get inspired by Rust's good parts as well.

The popularity of a programming language is not always about what the language offers. I would say a comprehensive, well-documented, mature set of standard libraries for its target audience is far more important (notable examples like R, Python, and Go). Last time I checked, Ada doesn’t even have a de facto, high quality TLS/crypto library, let alone various essential protocol/format codecs, yet the core team (AdaCore I assume) puts a lot of resources into offering a few sophisticated flagship IDEs that potential hobbyists would never use (they already have vim, emacs or vscode). I understand that as a business they have to sell something for revenue and they cannot sell standard libraries. So, that’s probably a dilemma that we cannot have the nice things for Ada to take off.

There's some thick bindings to libtls that coincidentally happen to be written by the author of the article. There's also some OpenSSL bindings in Dmitry Kazakov's Simple Components and some in Ada Web Server by AdaCore, although they're pretty minimal.

I think most applications of Ada are in embedded systems where you don't often want anything not in the standard library.

> I think most applications of Ada are in embedded systems...

Ada is heavily used and carries a historical influence not only with embedded software space, but also with hardware space: VHDL is one of the two major hardware description languages used in ASIC design and FPGA implementations. (The other language is Verilog, based on - you guessed it - C, because of its popularity.)

"Due to the Department of Defense requiring as much of the syntax as possible to be based on Ada, in order to avoid re-inventing concepts that had already been thoroughly tested in the development of Ada, VHDL borrows heavily from the Ada programming language in both concept and syntax." - https://en.wikipedia.org/wiki/VHDL#History

And databases on the software space, PL/SQL is heavily influenced by Ada, and pg/SQL is influenced by PL/SQL.

Also a package manager - Rust's is excellent and a huge reason to use it over C/C++. I see Ada has Alire but that seems like a fairly recent development and I don't know how it compares.

Very few of which are needed or even wanted for lower level mcu development. I assume when the gp was talking about spinning things they were talking about ESC software.

Ada is a lot of fun and a great thing which is ruined (and blessed) by the fact there's de facto only one implementation and company behind it out in the open, and that is semi-closed / license PITA. There were improvements over the years by AdaCore, but I think this altogether hurt the adoption of such a great language in general - no other wide open implementation (like Rust has). If you want to see an extreme example of such a hurt, take a look at Allegro CL and Franz; Imagine having that out in the open and what it'd do for CL, but at least CL has great alternatives in the open like SBCL, whereas Ada doesn't.

Not at all, there are 7 Ada compiler vendors still in business.

https://www.adacore.com/

https://www.ghs.com/products/ada_optimizing_compilers.html

https://www.ptc.com/en/products/developer-tools/apexada

https://www.ddci.com/products_score/

http://www.irvine.com/tech.html

http://www.ocsystems.com/w/index.php/OCS:PowerAda

http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm

And AdaCore sponsors GNAT, with Ada being one of the few official GCC languages for two decades now.

> out in the open

This part was an important part of the sentence you might've missed.

The original point is that there is only one open implementation. This is a link to that one open implementation. You are pushing this conversation around in circles.

How many open implementations are there for plenty of other languages, like the main implementations, driving the whole ecosystem, not partial implementations with if and buts?

How many open implementations are there of Rust?

(Serious question; I genuinely don't know. Always assumed it was about 1, though.)

Only 1, additionally there are two competing ones based on GCC still WIP, and an alternative backend (Cranelift) without the capabilities LLVM can offer in performance.

Do they all support the latest standards ?

A couple of them do, it isn't as if C and C++ FOSS compilers do as well.

https://en.cppreference.com/

C++23 and C23 are the latest, and there are plenty of missing features from previous standards.

As far as I'm aware, the compiler AdaCore sells is just GCC. You can install GCC built with Ada support from your distros package manager and it will just work. You can also download builds from here: https://github.com/alire-project/GNAT-FSF-builds

If something hasn't changed, FSF builds are a year behind libre version (by design), and libre version is GPL3 cancer which is not suitable for commercial development. You're then stuck either with a year old version or buy into AdaCore Pro version of it. Not great, not terrible.. but that's kind of the only game out in the open, which is what makes it different from most of other languages out there.

Why would the license of the compiler matter? It doesn't require you to license the code you compile with it accordingly.

runtime matters

Why? The code you compile isn't infected by the runtime license?

???

GNAT CE isn't a thing anymore, only FSF and Pro exist. And AdaCore now sponsors Alire, which installs FSF GNAT, and relicensed some of their tools more permissively.

Haven't looked in a while. That's great news then! Rust steals a lot of thunder these days though.

> and libre version is GPL3 cancer which is not suitable for commercial development.

YTF would GPL v. 3 be "cancer" for commercial development? (Shades of Ballmer; is Linux also "a cancer" to you?)

EULAs have all kinds of stupid shit in them already. Just make yours GPL3-compatible.

> As far as I'm aware, the compiler AdaCore sells is just GCC.

The compiler yes, but I'm convinced FOSS gnatprove must be outdated in some way: Last time I tried following AdaCore's SPARK manuals, certain basic aspects and pragmas didn't work correctly on the latest version.

Not to mention when SPARK aspects sometimes broke the LSP and formatter.

It's FOSS and is actually included with GCC, but the toolchain is still a PITA to install just because no one (other than Debian and Arch Linux) bothers packaging it. I think Alire is supposed to make it easy to install but I haven't used it much: https://alire.ada.dev/

SPARK 2014 itself is the same too AFAIK, the problem is there's a lot of auxiliary static analysis tools and plugins that are gated behind AdaCore's sales wall (and of course they'd never deign to sell licenses affordable to individuals)

The situation was pretty bad a few years ago, and the licensing was confusing but it's pretty straightforward now with Alire. (AdaCore also got rid of their "Community Edition which had the weird license restrictions).

I'm doing a presentation at FOSDEM next year called "Get started with Ada in 2 minutes or less!"[1]; because (on MacOS and Linux) I can go from not having no toolchain a all to compiling hello world in under 2 minutes (I've timed it).

Here's some steps:

1. open your terminal, run the following command: curl --proto '=https' -sSf https://www.getada.dev/init.sh | sh

Congratulations, you now have Alire!

2. Run the following command: alr init --bin hello

Now you have a fully structured Ada project, gpr files and all!

3. Edit your program in hello/src/hello.adb

You can use vscode to open the hello folder with the Ada Language server, or just run "alr edit" to open your editor with all of the files built in.

4. Compile with: alr build

Alire will automatically grab the latest native toolchain (gnat, gprbuild, etc) and compile the program.

If you want to use another toolchain, such as for cross-compiling, or another version of GNAT, simply run: alr toolchains --select

5. Run the program: hello/bin/helo

On windows, you can just download the windows installer; alire is also on Freshports for the BSDs.

[1] https://fosdem.org/2025/schedule/event/fosdem-2025-5056-get-...

Your step 1 violated my very hard rule against piping curl into a shell.

…and is ironic advice for a safety-critical system, no?

——-

(Yes, I’ve read arp242.net/curl-to-sh.html - but my point being that as I’d be new to Ada then I don’t know who to trust; I’ve never heard of getada.dev therefore I don’t trust it)

It's an understandable rule, and you can definitely just download the binary from alire.ada.dev and add it to $PATH but with such a harsh stigma around how difficult it is to get the toolchain set up, GetAda follows the precedent of Rust, where you can grab the toolchain via "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" (thanks to Rustup).

It was received positively at the time:

Show HN: Getada: rustup-like installer for Ada's toolchain/package manager 194 points | 115 comments: https://news.ycombinator.com/item?id=40132373

Is it really so bad to run it twice, with cat/bat replaced with sh on the second pass? If you're really paranoid about it you could save the first run to a file, so you know for certain that the server didn't do a switcheroo for the second one, but if you think about it, that's a low-payout move for Bad Guy #N compared to just sending the pwnage the first time around.

This is beside the fact that we're talking about downloading and running a user-owned binary, which, unlike the shell script, is impractical to inspect in any detail, and has the same privileges as the shell script we're supposed to worry about.

I view "don't curl to shell" as about 90% theatrics basically. Sure, read it first, I do in fact do that. But it's a silly 'very hard rule'.

I routinely save to a file before execution, but it's not really about being attacked. It's about the fact that those scripts, in order to be "fire and forget", make many assumptions, often very large ones, about where I want things or under what user, etc.

Many of them are actually quite well-written under the hood and can be easily moved to other directories, have comments about what it is doing, etc.

Here are the Rust installation instructions, that apparently is sooo much better,

https://www.rust-lang.org/learn/get-started

> The primary way that folks install Rust is through a tool called Rustup, which is a Rust installer and version management tool.

A couple of lines below

> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

I'm pretty sure that gentoo also packages ada, but it doesn't get installed by default, as its behind a USE flag.

Yeah, to this day Ada, though a beautiful language, is a hard choice to make if you are concerned about certain targets. How would i get my program to compile to Android NDK? Even Swift has a better story with it's tooling.

That's before we even talk about important stuff like libraries.

What are the options required to build an android gcc these days?

None since Google dropped GCC support, to anyone to do the work to make it work again.

Unless you are using the Android NDK with the official provided clang for C and C++, anything else is a pain for masochits that rather endure yak shaving the whole infrastructure than code in either C or C++ alongside either Java or Kotlin.

> no other wide open implementation (like Rust has)

So (at least according to pjmlp in https://news.ycombinator.com/item?id=42548360) Rust also only has a single "wide open" implementation.

Which means Rust doesn't have any "other" open implementation either, right?

Honestly, it's hard to know what of all the pro-Rust stuff one sees (here and elsewhere on-line) to take seriously, when its advocates constantly -- consciously or not -- exaggerate its virtues like this.

It suffered from high prices in compilers when it had an opportunity, plus Modula-2 and Object Pascal being good enough for those that cared about safety on 16 bit home computers.

It also didn't help that the UNIX vendors that had Ada compilers like Sun, it was an additional purchase on top of the development SKU that already had C and C++ included.

Memory safety and the borrow checker are useful even in the absence of dynamic memory allocation. This still doesn't bring rust and ada to the same place, but it is important to clarify that piece.

Spark supports borrowing which is easier to use than Rusts now. It also prevents memory leaks.

I never even knew that this "Ancient Language" had dependent types. Always thought it was a "modern" invention of snazzy newer academic languages like Idris, etc.

But, its easy to figure out why it didn't become popular. C/C++/any other top10 language all had free compilers available to everyone. Ada didn't during the explosive era of computing expansion. Also, not a problem nowadays with IDE auto-complete/snippets but the language was too verbose for older generation of programmers.

Verbosity was genuinely expensive at the time. Two ways: until the mid-80s, 5 1/4" floppies held between 100 and 250kB depending on format, so a program which used up three times as many bytes (I think that's a good multiplier from C to Ada) is making a meaningful difference for transfer, backups, storage.

What's probably more important is that 80 columns was far and away the likely maximum for a screen, and 40 columns wasn't unheard of. The word PROCEDURE took up 11 to 22% of the column width! This wasn't a show-stopper, Pascal uses a similar syntax (both of them derived from Algol of course) and was pretty popular, but plenty of people complained about Pascal's verbosity as well, and Ada is definitely more verbose than even Pascal.

The lack of autocomplete (even things like snippets were relatively uncommon) didn't help, but mainly, verbosity imposed real costs which are mitigated or irrelevant now.

You talk about C and C++ yet call Ada "ancient," C from 1969 and C++ from 1979.

Whereas Ada's first version is from 1980 and first standardised version (different to 1980) in 1983. Yeah, "ancient."

I really wanted to use Ada, at least learn it. Concepts are nice but I gave up when started looking into unicode support. It was wild, a bit discouraging. Or has the situation changed? What’s the unicode status in Ada?

You can embed and work with UTF-8 strings with no issue (I have source with emoji string literals), but if you need complex manipulation of code points vs glyphs etc. I’m not sure how robust the libraries are for what you are trying to do.

https://ada-lang.io/docs/learn/how-tos/gnat_and_utf_8/

Thank you, this is very useful information.

> We control things that spin real fast and our previous experiences with C definitely resulted in some screwups that left you weak in the knees for a bit.

Ha, you could almost read this as a stuxnet joke