Ada, a 45-year-old programming language, might just solve the very problems developers have been grappling with for years.

I realise that for many developers – particularly those who entered the industry this side of the millennium – Ada might conjure images of monolithic, over-engineered military programmes from a bygone era. It’s a language with a public relations problem, often perceived as archaic, verbose, and difficult.

For a long time, Ada fell out of favour and was overshadowed by the C++ behemoth and the rise of Java’s platform independence. But what if Ada wasn’t a product of its time, but a programming language well ahead of it? What if the very principles that made it seem rigid in the 1990s are precisely what we need to solve the software challenges of today?

Think about the biggest headaches we face today. The constant, nagging fear of security holes. The late-night calls to fix a critical vulnerability caused by a buffer overflow. This is why many developers are so rightly excited about Rust—it tackles memory safety head-on.

However, Ada was built for this from day one. Ada is a language that makes developers think before they type. Its strong, static type system isn’t there to annoy you; it’s there to catch your mistakes before they ever have a chance to cause chaos. It forces a discipline that, frankly, makes for better code that eliminates whole categories of common errors by its very nature.

Then there’s the performance conversation. We celebrate the raw speed of C++ and Rust programming languages, and we should, but Ada is right there with them, neck-and-neck.

And in an era where we’re deploying code to the cloud or to tiny IoT devices, Ada often pulls ahead where it often really matters: the size of the final programme. Its executables are impressively small. Think about your cloud bill. Think about the memory constraints on that new device. A smaller, faster programme is often a direct commercial advantage.

But here’s where I think Ada leaves almost every other programming language behind. We all test our code. We write unit tests, integration tests, and we hope we’ve caught all the bugs. But testing can only ever show that bugs are present; it can never prove they’re absent. Ada has a feature called Design by Contract, which lets developers build promises and requirements directly into their code. It’s a way of saying, ‘This function will not run unless you give it this, and I guarantee it will give you that in return.’

When you take that to the next level with its SPARK toolset, you can mathematically prove your code works. It’s the difference between crash-testing a car and proving through the laws of physics that it cannot fail in a certain way. For years, this has been the secret weapon of the aerospace and medical industries. The code running a jet’s flight controls or a surgical robot can’t just be ‘probably’ right.

Today we are building self-driving cars, we are letting AI manage financial systems, and we are trusting software with our health and safety more than ever. The ‘move fast and break things’ culture isn’t just irresponsible in this new world; it’s dangerous. The demand for software we can actually trust is becoming the single most important challenge of our time.

There’s a quiet satisfaction, and a little frustration, in realising that the problems the world is now desperately trying to solve with new tools and programming languages are the very same problems Ada was designed to prevent from the start.

Of course, I’m not saying we should all drop what we’re doing and rewrite everything in Ada. However, our collective blind spot has become a weakness. We owe it to ourselves to look at this powerful, safe, and incredibly efficient language not as a relic of the past, but as a potential blueprint for the future.

Back in July, Ada even managed to crack the top 10 of the TIOBE Index. The methodology of the index is often debated but, while Ada has since slipped back down, it suggests the old-timer isn’t as past its prime as many developers might think.

Perhaps the Ada programming language wasn’t behind the times but so far ahead that it’s taken us almost half a century to realise it.

We had a fully branded eSIM solution up and running in a week, with zero surprise costs.

We had a fully branded eSIM solution up and running in a week, with zero surprise costs.