Ada crate of the year 2024 announced | Hacker News Reader

Ada crate of the year 2024 announced

blog.adacore.com

106 pointsLionelDraghi65 comments

Ada was the first language they threw at us in university back in '98. At the time, it felt like learning Latin to become a poet, but looking back, those lessons—rigor, clarity, and discipline—have aged better than some modern frameworks. Ada may not trend on GitHub, but it quietly shaped a generation of better programmers.

Indeed. As a concrete example of one of those things Ada gets very right, it breaks down object-oriented programming into separate features of

- encapsulation,

- reuse,

- inheritance, and

- dynamic dispatch.

In Ada, you can opt into each of those things separately, depending on what you need “object-oriented programming” for. This is in big contrast to Java, where you type the keyword “class” and then all of that comes along for the ride.

I never truly understood OOP until I worked a bit with Ada.

Do you have some examples of this? Sounds interesting. But unsure what is different to plain composition approaches?

See https://learn.adacore.com/courses/intro-to-ada/chapters/obje...

If other languages just had the wonderful package and package body, they would have solved many or even most of my problems.

What kind of programs did they teach you to write in the language?

I believe for the same reasons that Latin helps develop a foundation in language, the people who designed it were looking at the problem from many different levels all at the same time. The first language I encountered with split behavioral / code components was Mesa at Xerox, and then Modula 2. (later VHDL but that's different?)

I think at the other end are lisp/forth list/stack languages which made this particular crate: https://github.com/BrentSeidel/Ada-Lisp-Embedded/tree/main/s... getting an award interesting to me. The combination of the two languages has an expressibility that individually they don't possess.

I’m not sure whether to agree or disagree with this perspective/analogy. On the one hand, Latin declinations prepare one for a wide variety of languages as diverse as English, French, and Russian, on the other hand the Roman Republic/Empire had such a wide influence - supposedly a third of the global population at its peak - that it’s hard to extricate the path dependency from the true influence of Romance languages.

There’s so much cross pollination in programming languages that I’m not sure where to draw the line. Even trying to probably isn’t worth the effort.

> a wide variety of languages as diverse as English, French, and Russian

As a linguist this makes me despair. These are all Indo-European languages, and not very exotic ones at that. It's like "as diverse as white, off-white, ivory, and bone." There are so many languages which would stretch your brain more.

I loved Latin back in the day, and Greek, but if you want exotic Indo-European languages, try Welsh or Old Irish. And if you want really exotic languages, leave Indo-European altogether. If you want to stick to Europe, try Basque, Finnish, or Hungarian. If you're willing to stretch your legs, try Seneca or Yindjibarndi. Swahili isn't too difficult, but it's very, very different from Latin. Hell, try Mandarin, though non-alphabetic writing systems kill my interest. Too much work on what I regard as a side point. If you want to make your brain explode (and who doesn't?), look into the Khoisan languages. Go here and listen to the speech sample.

https://en.wikipedia.org/wiki/Ju%C7%80%CA%BChoan_language

Amazing.

> As a linguist this makes me despair.

Why in god’s green earth would a random HN comment make you do that? I’m not a linguist and I have very limited experience beyond Indo-European languages, just like I have very limited experience with languages like Brainfuck or Ada - each of which might as well be as foreign to me as Mandarin or Swahili. I just didn’t bother to add that addendum because it would otherwise be a ten thousand word comment.

Laymen will be laymen. To despair over that is a path to nothing but torment.

Bro come on

Oh yes I'm screenshotting this for the textbook

I'll believe it when I see it. This smells like boarding-school braggadocio.

Has anyone developed in SPARK [0]?

My understanding, its significantly safer than Rust (and based on Ada) with equal performance.

A comparison chart of Ada vs Rust vs SPARK [1].

Most notable: Rust mainly provides memory safety ... but SPARK provides not just memory safety, but also safety from all run-time errors, formal properties, constraint checks, and more.

[0] https://en.wikipedia.org/wiki/SPARK_(programming_language)

[1] https://blog.adacore.com/should-i-choose-ada-spark-or-rust-o...

> My understanding, its significantly safer than Rust (and based on Ada) with equal performance.

Ada or Ada Spark? Ada Spark is more of a theorem prover, so the comparison to Rust is a bit weird.

It's true it's safer - it will protect you from a more programming errors, but you need more annotations to prove properties of a program.

I'd never seen [1] before. Thanks for the link! That's a great and even-handed discussion of the topic.

I've written a lot of hobby Ada code. I really like the language. Recently I did some research into how memory safety in Ada/SPARK compares with Rust[0]. My conclusion was that Rust is better at outright preventing common memory-related errors, but Ada has a lot of great features which let you avoid them in the first place. SPARK is a bit intimidating, but you can pretty much achieve parity with Rust on memory safety, and achieve a higher degree of safety overall. I got a real kick out of someone's comment on Reddit saying 'Both Ada and Rust benefit from not being C'.

0: https://ajxs.me/blog/How_Does_Adas_Memory_Safety_Compare_Aga...

Amazing blog post, learned a lot.

Thanks for writing & sharing it.

I recall my C++ class, via the University of California Extension program.

In the 1990s Bay Area, there was a catalog of hundreds of classes, taught after business hours or on weekends. The classes for security certification, or BGP routing, or C++, teacher and students were usually industry professionals.

We learned C++ object design of a style I would consider fairly strict, strong typing. Details escape me at the moment.

But I do remember the two graybeard Ada programmers sitting in the back of the room: "C++ compiler will accept that? Are you kidding?"

Raytheon or Honeywell, I think. Missile drivers.

Ada programmers.

Interesting that they decided to adopt the word "crate" (from Rust) for libraries published to the registry, and just like Rust they use TOML as a format for a package file.

Why is that interesting?

Ada influenced Rust, so it's interesting to see that influence flow backwards, too.

Ada has already "package" term used in a different context.

I haven’t tried Ada recently, but the issue I always have run into is setting up a toolchain that wouldn’t automatically force the binaries I compile to be GPLed. Is the story for writing and distributing MIT or Apache2 licensed software in Ada any better these days?

That's been a non-issue for several years now.

Good to know, I passed over Ada for Common Lisp around 2015 because of this.

I wonder if some misconception can have snuck in there somehow. GCC (which also has an Ada compiler) has its lowest level link libraries under GPL. But there's a link level exception. This is the same for C, C++, Ada, whatever languages GCC supports. (IIRC.)

(Edit: apparently it used to a problem as per sibling comment?)

The binaries AdaCore used to distribute stated that you had to get gnat elsewhere for this link level exception because the runtime library they distributed did not have the exception. But, I'm glad to know that this restriction has been solved.

Its interesting how PR works (I'm being earnest) . A library nobody uses for a language almost none of us will ever use (developed by the US government and never adopted for any project for any use case except where required by US contracting requirements, and even then almost always given an exception to not use it) is the top story on HN. Well done.

Please note: I'm not saying Ada is bad, it is a very interesting language and well ahead of it's time. I'm just saying it's not popular or in widespread use when compared to almost any other computer language you can list (which is just an objective fact), so it is interesting to me that this made it to #1. Please try to keep that in mind.

> and never adopted except where required by contract requirements

A lot of the software on the Boeing 777 is written in Ada. AFAIK, that was Boeing’s decision, not due to any government contract requirement-as a commercial aircraft, governments are not the primary customers

1) memory safety at compiler level, 2) type systems that have dependent types or similar such features, are both things people have gotten interested in again recently, especially because of the excitement around Rust. (you can see this connection from the use of the word "crate" here, which is a Rust term originally.)

Ada is a language that had features dealing with these problems way back in the 1980s, so people have suddenly become interested in revisiting it.

I agree it's an interesting footnote in computer history.

>1) memory safety at compiler level

Ada isn't memory safe. It doesn't have anything resembling a borrow checker. The spec used to allow an optional garbage collector, but that was never widely used in practice and was removed in Ada 2012. The average production codebase relies on Unchecked_Free/Unchecked_Deallocation for memory management.

I find it genuinely baffling that so many people who praise Ada clearly don't know and/or don't use the language.

Yep, and even without dynamic memory management, Ada is not type-safe: https://www.enyo.de/fw/notes/ada-type-safety.html

Rust also has soundness holes, by the way. This one is almost 10 years old: https://github.com/rust-lang/rust/issues/25860

Tons of languages have soundness bugs. While that one is ten years old, there have been zero reports of it ever being found in the wild, and it will finally be fixed relatively soon.

> it will finally be fixed relatively soon

2015: "The work needed to close this has not yet landed. It's in the queue though, once we finish up rust-lang/rfcs#1214."

Yes. For various other reasons, the trait system needed to be rewritten, and it would also end up fixing this. Since it’s essentially a theoretical issue, spending time on this wouldn’t make sense. In the meantime, that rewrite is nearing completion. The most recent version of rust uses it for coherence checking. The next few months are likely to remove several other stoppers from moving forward. It’s almost time for a crater run, and then fixing whatever issues that shows up.

The Rust one seems a specific bug in the implementation, while the Agda one seems more like a fundamental flaw caused by allowing aliased mutation though.

Ada/SPARK can be memory safe, in part because they borrowed ideas from Rust.

[0] https://blog.adacore.com/using-pointers-in-spark

You can't have the borrow checker without bringing the rest of SPARK with it as far as I'm aware, so this comes with the requirement that you prove the your program contains no other runtime errors.

i was very careful to use the vague phrasing "features dealing with these problems" and not "Ada has a borrow checker and dependent types".

Borrow checking is not the only way to achieve memory safety.

Pointers are memory safe as long as Unchecked_Deallocation/Unchecked_Access are never used thanks to how pointers have scopes, even though pointers can be pointing to variables on the stack.

You can go a very long way without ever touching Unchecked_Deallocation compared to C or Rust, even without allowing for use of the standard library where deallocation is done under the hood. I use it rarely enough that I have to go check the package specification every time I need it.

You also have relatively safe deallocation when you wrap your allocation in a storage pool and let RAII deal with it as the pointer system keeps you safe from a dangling reference if your container type only frees memory within the Finalize procedure.

You don't have the complete memory safety of a GC or Rust's borrow checker without SPARK, but you can completely avoid the unsafe parts or use well tested containers as opposed to C and other similar language where you need unsafe pointers to do anything non-trivial.

Haven't seen uncheched_deallocation in modern codebases in a long time... The secondary stack removes many/most use cases of short-lived dynamic allocation and pointer-passing. Controlled types, containers, alleviate most other use-cases. I'd frown at code review if I saw raw memory allocation. Memory safety issues I've seen (very rarely in 15 years of dev) hinge on aliasing, stack overflow (which you can mostly catch now) and tumbling down in C bindings.

I'll praise the language I use daily as far more memory-safe than the others I use daily (bar managed-memory Java-like languages).

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

https://news.ycombinator.com/newsguidelines.html

is rust reinventing the wheel here? i have been thinking rust is just the new Ada,but more complicated.

Rust is the new C++ but safe. That's what it is trying to be and pretty much what it is.

Ada is not a 'good' language by moderns standards. If you tried to use it you would probably be extremely frustrated. This isn't because it's poorly made, languages have grown a lot since the 80's. The C++ they wrote in 1985 would be extremely frustrating to work with by modern standards too.

Ada is also C++ but safe, so I don't see that as a refutation.

Ada has been a great language for lower-level code by my (modern) standards. I'm not sure what you're on about and the lack of concrete examples make it hard to guess.

> If you tried to use it you would probably be extremely frustrated.

I actually tried and it was surprisingly pleasant. Ada has also grown since the 80's, the last standard is from 2022.

Now, there're still some warts in the spec that I think are holding Ada back, but better UTF-8 support, simpler IO primitives (this could be a library) and a new profile without erroneous execution (i.e. memory safety without Spark) would fix most of them.

This is not a fair comment. Feel free to be a hater and spread unfair BS. We use Ada for years for its reliability, efficiency and readiness. We saved men/years thanks to its productivity. FYI, the latest Ada release is 2022 and still innovative.

A lot of us hold Ada in high regard. Your comment is a typical example of someone not realizing how much they don't know.

It only needed ~20 upvotes to get to the top story. You make it sound like they moved heaven and earth to get on here.

> never adopted for any project for any use case except where required by US contracting requirements

AFAIK, this is wrong. I've seen the language used for a core system continuously developed over decades at a financial institution with no link to the US, for instance.

It's also used in aerospace and safety critical systems work in Europe, though I'm not sure the extent. In the US, post-mandate, that work is almost all Fortran, C, C++, or now maybe Rust (I'm meaning work that started after the mandate, pre-mandate it was more varied).

787 was the newest system I worked on in the US that used Ada, and that was optional for the software vendors. I think the OS our software ran on was written in Ada, though.

Ada would count as an exotic / niche language for most of this community and those are perennially popular on HN. That's sufficient to explain the upvotes (which looked legit to me when I checked the data).

Also, these things tend to come in waves, even though we try to discourage that, and this was on the frontpage for 10 hours yesterday:

Ada Gems (2014) - https://news.ycombinator.com/item?id=42986149 - Feb 2025 (9 comments)

Reply on news.ycombinator.com