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.
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.
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.
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.
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'.
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?"
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.
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?
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.
The same can be said for FORTRAN and COBOL which both have 2023 standards and are still widely in use.
Programming languages do not age the same way as physical objects. Merely being old does not make them less useful and in many cases the code that was written decades ago still works fine.
I do too. The crazy thing is that LtU stopped being updated frequently at a time when there was (what seemed to be) a sort of renaissance in PL research
Hacker News only posts about languages nobody uses. There are more posts about D than there are about Java. Ada is being marketed because it's obsolete and no one uses it.
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.
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:
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.
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.
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.
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.
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).
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.
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.
> 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.
> 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
It is not just one airplane. It is still common in defense and aerospace software, as well as other safety critical code (Nvidia recently started using the SPARK subset for some of their firmware I believe). Just because you don’t know anyone using it doesn’t mean it isn’t used.
Ada is the basis of SPARK, [0] which takes Ada and adds formal verification.
While no doubt massive overkill for 99.9% of applications, there are a small number of use cases (safety-critical or security-critical code) where it can actually make sense.
While in principle you could add formal verification to other languages, I'm not aware of any other such solution with as much mindshare as SPARK. Ada's feature set is already closer to what you need for that purpose than what many other languages offer, so even though SPARK still has to both subset and superset Ada, the same thing with other languages would arguably require both taking more away and adding more.
We've been starting code bases in Ada for embedded consumer power generation products for the last year. Huge improvement over C, nobody on the team has any regrets.
Just because it isn't topping the TIOBE index doesn't mean it doesn't have its place.
> 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.
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.
