Ada Is a Memory-Safe Language. It's Also Not New. That's the Point.

May 04, 2026

Blog

Few people are familiar with Ada nowadays, though it has a long and distinguished history. If you're building high-integrity software, such as flight control software, a medical device, an industrial controller, or similar devices where failure is expensive or can lead to injury, and you're still writing C, you should really take a look at Ada. Moving from C to Ada was not an option for many projects. Still, with the availability of automatic translation of C code to Ada using Large Language Models (LLMs), this situation has changed. Are you skeptical? Read on and see how you can convert code in 15 mins.

Ada Is Not a Museum Piece

The word "Ada" tends to evoke images of Fortran-era batch jobs and government procurement forms. That image is wrong.

Ada 2022 is a modern language. It has:

• Object orientation with full inheritance and dynamic dispatch
• Generic types (think C++ templates, but with constraints that actually catch errors at compile time)
• Native concurrency primitives through the tasking model, built into the language spec, not bolted on through a library
• Contract-based programming with preconditions, postconditions, and type invariants
• Protected objects for safe shared state without the footguns of raw mutexes

The toolchain is mature. GNAT is production-grade, the Alire package manager works like you'd expect a modern package manager to, and companies like AdaCore have been shipping tools for high-integrity development for over 30 years. This is not a research project. On top of all this, all tools are available in open source, allowing developers to get started in literally minutes.

The C Migration Problem Nobody Wants to Solve Manually

The practical blocker isn't language capability. It's the existing C code.

Most teams working on safety-critical systems have millions of lines of C that run correctly enough, have survived years of debugging, and nobody wants to touch. A full rewrite is not a conversation most engineering leads can have with a straight face. The business case doesn't close, the risk is enormous, and the institutional knowledge embedded in that codebase doesn't survive a flag-day rewrite.

But a full rewrite isn't the only option.

Ada and C interoperate cleanly. Ada has first-class support for calling C functions and being called from C through its `Interfaces.C` package. You can run Ada and C side by side in the same binary. That means you can convert selectively, starting with the parts of the codebase that have earned that attention through defect reports, CVEs, and late-night incident calls.

Using AI to Do the Actual Work

This is where it gets interesting. LLMs are reasonably good at mechanical code translation. Converting C idioms to Ada equivalents is exactly the kind of structured, pattern-heavy task they handle well. The translation from pointer arithmetic to Ada array types, from `malloc`/`free` to controlled types, from `pthread_mutex` to Ada protected objects follows predictable rules.

An agentic LLM  can take a C source file and produce a corresponding Ada implementation. The output won't be perfect on the first pass. That's fine, because you have tests and the agent can iterate over them till they all pass.

The workflow looks like this:

1. Pick a module with known defects and good test coverage
2. Run the LLM against the C source, asking for an Ada translation
3. Interface the module with your existing code base (if not standalone)
4. Run your existing test suite
5. Feed failing tests back to the AI agent as context
6. Iterate until the tests pass
7. Do a code review before merging

Step 5 is what makes this tractable at scale. The agent uses test failures as a feedback signal to correct its own mistakes. You're not manually reviewing every line of generated code cold; you're reviewing code that already passes your test suite. That's a much faster review.

Step 7 is what keeps you in control; you see the changes. Even better, if you do a commit before the first test run, you can now see the diff between the initial translation and the fixes the LLM applied to make the tests pass.

Containing the agent to a specific part of the codebase is straightforward with Dev Containers. Mount only the module you're converting, give the agent access to the relevant headers and test harness, and it can't accidentally wander into code you're not ready to touch.

This process is not fully hands-off. Code review is still required. But the mechanical labor of translation and a good chunk of the debugging can be automated.

Now, this is not native Ada code; it is translated from C. Native Ada code would use different types for different concepts, for example, but at least you now have your logic in a memory-safe environment, and you can gradually improve.

Getting Started in Under an Hour

To try this quickly, [Alire](https://alire.ada.dev) gets you a working Ada environment in minutes. You can use your own product code, or you can use some open source code to get your feet wet:

```bash

# Install Alire, then:

alr init dining_philosophers  # or start a new crate

cd dining_philosophers

alr build

alr run

```

The Dining Philosophers problem is a good first target. It's small enough to be manageable, it involves concurrency, and Ada's tasking model handles it in a way that makes the synchronization structure explicit and readable rather than implicit and fragile. Take any C implementation you find online, give it to an LLM, ask for an Ada translation, and see what comes back. The whole exercise takes less than 15 minutes.

The Ceiling Is Higher Than You Think

Memory safety is the floor. Ada's real ceiling is formal verification through SPARK.

SPARK is a subset of Ada that excludes features that are hard to reason about formally (things like aliasing and dynamic dispatch in specific contexts). The GNATprove tooling can analyze SPARK code and produce mathematical proofs about it, using a sound, automated prover. And again, it is available in open source through Alire.

The verification levels are progressive:

- **Stone**: valid SPARK, no formal proofs yet

- **Bronze**: no uninitialized variables, no illegal information flow

- **Silver**: absence of runtime errors, buffer overflows, division by zero, and numeric overflow.

- **Gold**: functional correctness. The code does what the specification says it does.

You don't have to commit to Gold on day one; adoption is incremental. Start in Ada, get the memory safety and the type system. Add SPARK annotations to a critical module. Run GNATprove and see how long it takes to reach Silver. For the Dining Philosophers, it will take minutes. Each step is independent and reversible.

For functional safety work, following standards such as DO-178C, IEC 61508, ISO 26262, and others, Silver alone eliminates entire categories of findings. Gold is where you can make claims that your verification and validation team can actually sign off on.

None of This Requires a Budget Approval

The GNAT compiler, Alire, and GNATprove are all available as open source, enabling developers to easily get started with Ada and SPARK. The open-source toolchain supports building for development workstations and many embedded targets. AdaCore offers commercial support and tooling for production programs, but you can evaluate every concept in this article without spending anything.

Take the Dining Philosophers problem, write it in C, or grab the implementation provided, hand it to an agent, and get an Ada translation in under 15 minutes. Run GNATprove on it and eliminate runtime errors in another 10. The toolchain works. The language is real. Getting that same program to Gold-level correctness is a worthwhile next step and a topic for another post.