Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ada is so stable and backwards compatible that old libraries will work just fine, unless they have external dependencies or depend on things that change fast in the outside world.

For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to write, read and maintain than idiomatic Ada, and 3) it's fast changing. The good thing about Ada is that it is self-documenting, it's almost impossible to intentionally or unintentionally obfuscate it, and once you've written a program it will continue to work 10-20 years later.




I think a lot of people would disagree with #1. There was a discussion on /r/technology yesterday where people were discussing how it was exactly the other way round – Ada has weird syntax (so many English words!) which slows adoption, and Rust is C-like enough that the target market of C/C++ users can pick it up, syntactically at least. I'm saying this having done a distributed systems course in Ada. It felt like writing a novel, about some very awkward people announcing every action as they did it. Rust, on the other hand, feels like pair programming with a wizard (the compiler) who knows how to write really great C++ and has many tips to share.

Rust's syntax is, like many new languages as they are invented, essentially a pick of the crop of the best syntax ideas from other languages. 'Best' is probably debatable but familiarity is certainly not. Type annotations are basically Scala syntax. Class::method(), ditching `return` in favour of last-line expressions and the || {} closure syntax are all pretty close to Ruby. Structs/enums are also basically Scala. `instance.method()`, and pretty much the rest of the language, is universal.

It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher. Much easier than trying to figure out function pointers in C, if you ask me.

#2 is probably true, but that's the cost of staying close to the metal. Rust makes all your memory access very explicit, rather than bundling it up in the standard/GC or leaving it to you. But it's a model you can get used to, and it has value as a mental model aside from its application in Rust.

#3 – well. Ada was young once. Rust is incredibly stable for a project designed by a distributed community of Mozilla and a ton of volunteers.


> Structs/enums are also basically Scala.

How so? Scala class bodies are a mix of ordered constructor statements and unordered declarations/method definitions, while Rust structs can only declare fields (without any sort of initial value). Scala enumerations (both scala.Enumeration and the more common sealed class versions) look nothing like a Rust enum; if anything Rust enums look like ML/Haskell algebraic type definitions.

> It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher.

The part of the type syntax that is like Scala (i.e. the colons and arrows) has its origins in the ML family IIRC. Rust's bootstrapping compiler was written in OCaml, so I suspect that was in fact the inspiration.


Ah, I see it's been a while since I've used Scala. I think I should have referred to case classes. Weak point nonetheless.

I did fail to mention the other very Scala thing: match expressions. Most complicated Rust match expressions could almost compile without errors in Scala.


If you start a project today that depends on a library that was last updated in 2002, then may God help you.


Why? Ada libraries from 2002 without outside dependencies work perfectly fine. I'm using that old libraries all the time. Ada has been designed specifically for that, it's been used in the aviation industry that runs the same code for 20+ years minimum.

That you think otherwise only shows that you've never seriously used Ada in a larger project.


The keyword is "without outside dependencies " . Most of us have to integrate many systems and there outdated libraries are a big problem.


The last version of DOS also works really well for the things it was designed for. You still wouldn't start new projects targeting DOS if you could help it, even if it would satisfy your current requirements.


Well, we're talking a safe language. So, if want an archaic red herring, you'd be better bringing up Burroughs written in an Ada predecessor that was immune to most forms of code injection or crashes in 1961. If you want small and Ada, then Martes RTOS is one written in Ada that's still around. For small and secure, the Muen separation kernel can handle it.


Actually, I would, if my needs were simple enough. Rarely is it necessary to have much more in embedded fields. Have a look at MDOS, a modern reimplementation of DOS used in many modern embedded cases.

Edit: which is apparently now called adelian.


Well, why? Why would a library be bad just because it hasn't been updated in 15 years? Does it spoil? Maybe it doesn't need to be updated.


The current RFC for the base LDAP protocol is from 2006, so that is at least 4 years of potential updates/changes that are missing from the library.


Environment rot, yes (protocol changes, bug that weren't found yet by the time that library come out, etc...).


There are environment and protocols that don't change much. Typically the places where Ada is used.


Libraries that interface with other systems like LDAP go bad over time. Either you are missing bug fixes or new features.


Same goes for a library that was last updated 5 minutes ago though.


Good point. I'd rather pick the one that hasn't needed an update in 20 years unless they're assuming it is bitrotten.


How do you distinguish between "hasn't needed an update" and "was abandonded by the developer"?


Probably isn't always easy.


Welcome to VB6.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: