Diff — Ada vs Rust: The Memory Safety Showdown

{{date|2026-10-13}}

# Ada vs Rust: The Memory Safety Showdown

The numbers are not in dispute. **Seventy percent** of all security vulnerabilities at Microsoft are memory safety bugs. The same figure holds at Google, Apple, and across the Linux kernel. Android alone tracked 223 memory safety vulnerabilities in 2019; by 2024 that number had fallen to 36 — a direct consequence of writing new code in Rust instead of C and C++. The U.S. National Security Agency, the White House, CISA, the FBI, and cybersecurity agencies from five allied nations have all issued the same recommendation: **stop writing new code in memory-unsafe languages**.

---

## Why: the 70% problem

The memory safety crisis is not a theoretical concern. It is the single largest source of exploitable vulnerabilities in the software that runs the modern world.

### The data

| Organization | Finding | Year |

|---|---|---|

| **Microsoft** | ~70% of all CVEs assigned each year are memory safety bugs | 2019 (confirmed ongoing) |

| **Google (Chrome)** | ~70% of serious security bugs are memory safety issues | 2020 |

| **Google (Android)** | Memory safety vulnerabilities dropped from 76% to 24% of all Android CVEs after prioritizing Rust for new code | 2019→2024 |

| **Apple** | Majority of exploited-in-the-wild iOS bugs are memory corruption | 2023 |

| **CISA / FBI / NSA / Five Eyes** | 52% of critical open-source projects are written primarily in memory-unsafe languages | 2024 |

| **Linux kernel** | Memory safety bugs account for the majority of exploited kernel vulnerabilities | Ongoing |

```fact

The consistency of the 70% figure across completely independent organizations — Microsoft, Google, Apple, the Linux kernel project — is what makes it so damning. These are not the same codebases, the same developers, or the same development processes. The constant is the language: C and C++. The bug class is a property of the tool, not the programmer.

```

### What "memory safety" actually means

A memory-safe language prevents, at compile time or runtime, a specific set of errors:

| Bug class | What happens | Consequence |

|---|---|---|

| **Buffer overflow** | Writing past the end of an array | Arbitrary code execution, data corruption |

| **Use-after-free** | Accessing memory that has been deallocated | Crashes, data corruption, exploitable dangling pointers |

| **Double free** | Freeing the same memory twice | Heap corruption, exploitable |

| **Null pointer dereference** | Following a pointer that points to nothing | Crashes, denial of service |

| **Uninitialized memory read** | Reading a variable before it has been assigned | Information leakage, unpredictable behavior |

| **Data race** | Two threads accessing the same memory without synchronization | Non-deterministic behavior, exploitable |

[[File:pentagon-aerial.jpg|right|280px|The Pentagon — the DoD whose 1970s software crisis led to Ada and whose agencies now recommend memory-safe languages. Public domain.]]

These are not abstract concerns. Each of these bug classes has been exploited in real attacks against real systems, causing real damage — from the Morris Worm (1988) to Heartbleed (2014) to the Blastpass zero-click exploit chain targeting iOS (2023).

In C and C++, **all six** of these bug classes are possible and common. The languages provide no compile-time or runtime protection against any of them (with limited exceptions for bounds-checked containers in modern C++). The programmer is trusted to get it right every time, in every function, in every edge case, in every concurrent interaction, forever.

The data shows, consistently and across decades, that programmers do not get it right. Not because they are incompetent — some of the best engineers in the world work at Google, Microsoft, and on the Linux kernel — but because the task is beyond human reliability at scale. A million-line C codebase contains millions of opportunities for these errors, and a single one is enough for an attacker.

---

## The government response

The institutional response to the memory safety crisis has been unprecedented in the history of programming languages.

### NSA (November 2022)

The NSA published a Cybersecurity Information Sheet titled **"Software Memory Safety"** (CSI-SOFTWARE-MEMORY-SAFETY), explicitly recommending that organizations "use a memory safe language when possible." The sheet named specific languages: **Rust, C#, Go, Java, Ruby, Swift** — and **Ada**. The NSA distinguished Rust as the preferred option for systems programming (where garbage collection is unacceptable), and Ada as the established choice for safety-critical embedded systems[1].

### White House ONCD (February 2024)

The White House Office of the National Cyber Director published **"Back to the Building Blocks: A Path Toward Secure and Measurable Software,"** calling C and C++ languages that "lack traits associated with memory safety" and stating that "choosing to build in a memory safe programming language is an early architecture decision that can deliver significant security benefits." The report called memory-safe language adoption "the highest leverage method to reduce memory safety vulnerabilities"[2].

### CISA / FBI / Five Eyes (2023–2024)

CISA, the FBI, the NSA, and cybersecurity agencies from Australia, Canada, New Zealand, and the United Kingdom jointly published **"The Case for Memory Safe Roadmaps"** (December 2023), recommending that all software manufacturers create roadmaps for transitioning to memory-safe languages. A follow-up report (June 2024) analyzed 172 critical open-source projects and found that **52% were written primarily in memory-unsafe languages**[3].

```quote

"We, as a nation, have the ability — and the responsibility — to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem, but that means we need to tackle the hard problem of moving to memory safe programming languages." — Harry Coker, U.S. National Cyber Director, February 2024

```

### The cost of doing nothing

The financial impact of memory safety vulnerabilities is staggering. A 2024 Consortium for Information and Software Quality (CISQ) study estimated that poor software quality costs the U.S. economy **$2.41 trillion per year**, with a significant fraction attributable to security vulnerabilities rooted in memory-unsafe code. Individual incidents tell the story in human terms:

- The **Heartbleed** vulnerability (2014) — a buffer over-read in OpenSSL's C code — exposed the private keys and user data of an estimated 17% of all TLS-secured web servers worldwide. The cleanup cost tens of billions of dollars.

- The **WannaCry** ransomware (2017) exploited EternalBlue, a Windows SMB vulnerability rooted in C code, causing an estimated **$4–8 billion** in global damages and crippling the UK's National Health Service.

- The **SolarWinds** attack (2020) exploited multiple memory-corruption vulnerabilities. The U.S. government's remediation alone cost hundreds of millions.

Every one of these incidents traces back to a memory safety bug in C or C++ code. Every one was preventable with a memory-safe language.

This is not guidance from a vendor or a language community. This is the combined weight of the United States intelligence community, the executive branch, and five allied nations telling the software industry: **the way you have been writing systems software for fifty years is a national security risk, and it needs to change**.

---

## Can: what Rust brings to the fight

[[Rust_(programming_language)|Rust]]'s approach to memory safety is built on a single insight: **ownership**. Every value in Rust has exactly one owner. When the owner goes out of scope, the value is dropped (deallocated). References to values are governed by the **borrow checker**, which enforces two rules at compile time:

1. You can have either **one mutable reference** or **any number of immutable references** to a value, but not both simultaneously.

2. References must always be **valid** — they cannot outlive the value they point to.

These two rules, enforced statically by the compiler with zero runtime cost, eliminate use-after-free, double-free, data races, and dangling pointers **at compile time**. No garbage collector. No runtime overhead. No escape.

### What Rust prevents (and how)

| Bug class | Rust's defense | Mechanism |

|---|---|---|

| Buffer overflow | Bounds checking on all array/slice accesses | Runtime check (panic on out-of-bounds) |

| Use-after-free | Ownership system; values dropped when owner goes out of scope | Compile-time (borrow checker) |

| Double free | Single ownership; cannot free what you don't own | Compile-time |

| Null pointer dereference | No null pointers; `Option<T>` forces explicit handling | Compile-time (type system) |

| Uninitialized memory | All values must be initialized before use | Compile-time |

| Data races | Borrow checker prevents shared mutable access across threads | Compile-time |

### The Android proof

Google's Android team provides the most compelling real-world evidence for Rust's effectiveness:

- **2019**: 76% of Android vulnerabilities were memory safety bugs (223 total)

- **2024**: 24% of Android vulnerabilities were memory safety bugs (36 total)

- **2025**: Memory safety vulnerabilities fell below **20%** for the first time

- Rust code in Android shows a **1,000x lower** memory safety vulnerability density than C/C++ code

- Rust changes have a **4x lower rollback rate** than C++ changes

- Rust changes spend **25% less time** in code review than C++ changes

```fact

Google's approach is strategically important because they did not rewrite their existing C/C++ codebase. They simply wrote **new code** in Rust and let the old code age in place. The old code, being older, is more thoroughly tested and contains fewer new bugs. The new code, being Rust, introduces fewer memory safety bugs. The combined effect is a dramatic decline in total memory safety vulnerabilities — without the cost or risk of a massive rewrite. This is the model that most organizations will follow.

```

### Rust's certification story

Rust's historical weakness in safety-critical domains — the lack of qualified compilers — is closing fast. **Ferrocene**, developed by Ferrous Systems, is the first open-source Rust compiler qualified for safety-critical use:

- **ISO 26262** (automotive): qualified to **ASIL D / TCL 3** — the highest risk classification

- **IEC 61508** (industrial): qualified to **Class T3**

- **IEC 62304** (medical devices): qualified as of Ferrocene 24.11.0

- **DO-178C** (aerospace): qualification support for **DAL C** is available

Ferrocene does not yet match Ada/SPARK's certification depth (Ada compilers have been qualified to DO-178C DAL A — the highest aviation level — for decades), but it is closing the gap rapidly. For automotive, industrial, and medical applications, Ferrocene already provides the certification evidence that regulated industries require.

---

## Can: what Ada/SPARK brings to the fight

[[Ada_Programming_Language|Ada]] and [[SPARK_Ada|SPARK]] take a fundamentally different approach. Where Rust prevents **memory errors** at compile time, Ada prevents a broader class of errors through **strong typing, range constraints, and runtime checks**, and SPARK goes further by **mathematically proving** the absence of errors for all possible inputs.

### What Ada/SPARK prevents (and how)

| Bug class | Ada's defense | SPARK's defense |

|---|---|---|

| Buffer overflow | Array bounds checking at runtime (`CONSTRAINT_ERROR`) | **Proven impossible** at compile time by GNATprove |

| Integer overflow | Range constraint checking at runtime | **Proven impossible** at compile time |

| Type confusion | Strong nominal typing; no implicit conversions | Same + flow analysis |

| Null pointer | Access checks at runtime | Pointer-free subset; ownership model in SPARK 2014 |

| Uninitialized variables | Compiler warnings; runtime checks | **Proven initialized** by flow analysis |

| Division by zero | Runtime `CONSTRAINT_ERROR` | **Proven impossible** at compile time |

| Logic errors | Not prevented | **Proven correct** against contracts (Pre/Post) |

The critical row is the last one. **SPARK can prove functional correctness** — that the program computes the right answer, not just that it doesn't crash. Rust's borrow checker guarantees memory safety; SPARK's GNATprove can guarantee that a binary search actually finds the element, that a cryptographic function actually produces the correct output, that an autopilot controller actually commands the correct control surface deflection.

### The deployment proof

Ada/SPARK's track record in safety-critical systems is unmatched:

- **Boeing 777**: 99.9% of avionics software is Ada

- **F-22 Raptor**: mission software written in Ada

- **Eurofighter Typhoon**: Risk Class 1 (most critical) software in SPARK

- **iFACTS** (UK air traffic control): 250,000 lines of SPARK, 153,000 verification conditions, 98.76% proven automatically, operational 24/7 since 2011, handling 5,500 flights per day

- **MULTOS** smart card: SPARK code certified to ITSEC E6 — the **highest commercial security evaluation ever achieved**

- **Paris Métro Line 14**: driverless train control in SPARK, certified SIL 4

No Rust program has yet been deployed in a system certified to DO-178C DAL A, EN 50128 SIL 4, or Common Criteria EAL6+. Ada/SPARK has been there for decades.

The gap is not just about certification paperwork — it is about proven operational history. The Boeing 777 has been flying with Ada avionics since 1995. The Paris Métro Line 14 has been running with SPARK signaling since 1998. iFACTS has been handling 5,500 flights per day since 2011. These are not test deployments or proof-of-concept projects — they are production systems that millions of people depend on every day, running code that has been formally verified or exhaustively tested over decades. Rust's certification story is promising, but it is measured in years; Ada/SPARK's is measured in decades and millions of flight-hours.

---

## The technical deep dive: how they actually work differently

Understanding the difference between Rust and Ada/SPARK requires looking at what happens when you write a simple function in each.

### Rust: the borrow checker in action

```rust

fn find_max(data: &[i32]) -> Option<&i32> {

    if data.is_empty() {

        return None;

    }

    let mut max = &data[0];

    for item in &data[1..] {

        if item > max {

            max = item;

        }

    }

    Some(max)

}

```

The borrow checker guarantees: `data` is borrowed immutably, so no other code can modify it while `find_max` is running. The returned reference `&i32` has the same lifetime as `data`, so it cannot outlive the array. The `Option<&i32>` return type forces the caller to handle the empty case. All of this is checked at compile time with zero runtime cost.

What Rust does **not** guarantee: that the function actually returns the maximum element. It could return the minimum, or the first element, or any element — the borrow checker would accept all of these. Rust guarantees memory safety, not logical correctness.

### SPARK: the prover in action

```ada

function Find_Max (Data : Integer_Array) return Integer

   with Pre  => Data'Length > 0,

        Post => (for all I in Data'Range => Find_Max'Result >= Data(I))

                and then

                (for some I in Data'Range => Find_Max'Result = Data(I))

is

   Max : Integer := Data(Data'First);

begin

   for I in Data'First + 1 .. Data'Last loop

      pragma Loop_Invariant

        (for all J in Data'First .. I - 1 => Max >= Data(J));

      pragma Loop_Invariant

        (for some J in Data'First .. I - 1 => Max = Data(J));

      if Data(I) > Max then

         Max := Data(I);

      end if;

   end loop;

   return Max;

end Find_Max;

```

GNATprove guarantees: no array out-of-bounds access, no integer overflow, **and** the function returns a value that is greater than or equal to every element in the array **and** is actually present in the array. This is not testing — it is a mathematical proof that holds for all possible input arrays of any length.

The cost: the programmer had to write the `Pre` and `Post` contracts and two `Loop_Invariant` pragmas. This is the price of functional correctness. It is non-trivial work, but it produces a guarantee that no amount of testing can match.

---

## The comparison: where each language wins

This is not a simple "one is better" question. The two languages win in different dimensions:

| Dimension | Rust | Ada/SPARK | Winner |

|---|---|---|---|

| **Memory safety (compile-time)** | Borrow checker eliminates use-after-free, double-free, data races | Strong typing prevents type confusion; SPARK proves bounds safety | **Tie** (different mechanisms, similar outcome) |

| **Functional correctness** | Not addressed by the language | SPARK proves programs satisfy their contracts | **Ada/SPARK** |

| **Ecosystem size** | 170,000+ crates on crates.io | Hundreds of Alire crates | **Rust** (by orders of magnitude) |

| **Learning curve** | Steep (borrow checker) but well-documented | Steep (language + contracts) with smaller community | **Rust** (better resources) |

| **Certification maturity** | Ferrocene: ISO 26262 ASIL D, DO-178C DAL C | Decades of DO-178C DAL A, EN 50128 SIL 4, CC EAL7 | **Ada/SPARK** |

| **Concurrency safety** | Borrow checker prevents data races | Ravenscar/Jorvik profiles with formal schedulability analysis | **Ada/SPARK** (for hard real-time) / **Rust** (for general async) |

| **Industry adoption (2026)** | Linux kernel, Android, Windows, AWS, Cloudflare, Discord | Avionics, defense, railway, smart cards, air traffic control | **Rust** (breadth) / **Ada/SPARK** (depth in safety-critical) |

| **Hiring pool** | Growing fast; top-10 language | Small, aging, expensive | **Rust** |

| **Government backing** | Named by NSA, White House, CISA | Named by NSA; created by DoD | **Tie** |

| **Cost of adoption** | Free toolchain, vibrant community | GNAT CE free; SPARK Pro commercial; Alire growing | **Rust** |

```fact

The VDC Strategy 2026 survey of 500+ embedded software decision-makers ranked Ada, SPARK, and Rust as the three best languages for meeting safety and security requirements. 85% of engineers reported that programming language choice directly impacts safety and security. The survey found both Ada and Rust adoption growing in embedded systems, with Rust rising faster from a lower base and Ada holding steady in its traditional safety-critical strongholds.

```

---

## Will: the adoption question

### Rust's trajectory

Rust is on an unprecedented adoption curve for a systems language:

- **Linux kernel**: Rust code accepted since Linux 6.1 (2022); Rust-based drivers in production (ASIX Ethernet PHY, Apple GPU "Nova")

- **Android**: Google's primary language for new native code; memory safety bugs down 68% in five years

- **Windows**: Microsoft writing portions of the Windows kernel in Rust

- **AWS**: Firecracker (Lambda microVMs), Bottlerocket (container OS), s2n-tls — all Rust

- **Cloudflare**: Pingora (HTTP proxy serving ~1 trillion requests/day) replaced NGINX, written in Rust

- **Embedded**: C usage in embedded projects dropped from 80% (2005) to 42.5% (2026); Rust grew to 6.8% and is projected to reach 14% within three years

- **1Password, Dropbox, Discord, Figma**: major consumer applications with Rust backends

- **Let's Encrypt / Prossimo**: Rust-based TLS library (rustls) replacing OpenSSL's C code in critical internet infrastructure

The productivity data is equally compelling. Google reports that Rust code changes in Android require 20% fewer revisions during code review, spend 25% less time in review overall, and have a 4x lower rollback rate than C++ changes. This challenges the conventional wisdom that safety comes at the expense of developer velocity — at Google's scale, the safer language is also the faster one.

The numbers are clear: Rust is gaining ground faster than any systems language in history. But it is gaining ground primarily in **new code** and **new projects**. The hundreds of billions of lines of existing C and C++ code are not being rewritten — they are aging in place.

### Ada/SPARK's trajectory

Ada's adoption is quieter but equally real in its domain:

- **AdaCore** reported "a significant increase in design wins across US aerospace and defense programs" in 2026

- The **NSA** and **White House** memory-safety recommendations explicitly include Ada

- **SPARK 2014** dramatically lowered the barrier to formal verification

- The **Alire** package manager brought modern dependency management to Ada

- **Ferrocene's** success is creating pressure on Ada toolchain vendors to match Rust's accessibility

Neither Rust nor Ada/SPARK will rewrite the estimated **hundreds of billions of lines** of existing C and C++ code. The Linux kernel alone is over 30 million lines of C. Windows is tens of millions of lines of C and C++. Chromium is over 35 million lines of C++. The global telecommunications infrastructure, the world's embedded systems, the firmware of every router, every printer, every industrial controller — all C.

The realistic migration path is Google's: **write new code in a memory-safe language and let old code age in place**. The old code, being older and more tested, has fewer undiscovered bugs. The new code, being memory-safe, introduces fewer new bugs. Over time, the percentage of memory-unsafe code decreases and the vulnerability count drops. This is not a revolution — it is a gradual, measurable improvement. And it is already working.

For the C/C++ code that cannot be replaced — kernel code, legacy embedded systems, performance-critical inner loops — the mitigation strategy includes:

- **Sanitizers** (ASan, MSan, TSan) for testing

- **Static analyzers** (Coverity, CodeQL, clang-tidy)

- **Coding standards** (MISRA C, CERT C, SEI CERT C++)

- **Hardening** (stack canaries, ASLR, CFI, shadow stacks)

- **Incremental Rust integration** (Rust-for-Linux, C++/Rust interop)

None of these approaches is as effective as writing in a memory-safe language in the first place. But for legacy code, they are the practical reality.

Ada is not growing in web servers or mobile apps — it was never going to. It is growing in the domains where its strengths are irreplaceable: avionics, defense, railway, nuclear, and medical devices. The memory safety mandate has given Ada new relevance, because regulators and procurement officers are now explicitly asking for memory-safe languages — and Ada has been memory-safe since 1983.

---

## Should: choosing your weapon

The answer depends on what you are building and what failure costs:

### Choose Rust if:

- You are writing **new** systems software (infrastructure, networking, OS components, CLI tools, web backends)

- You need a **large ecosystem** of libraries and frameworks

- Your team can learn the borrow checker and you have access to Rust developers

- You need **memory safety without a garbage collector** but do not need formal proof of functional correctness

- You are in **automotive** (Ferrocene is already qualified to ASIL D)

- You want to **interoperate with C/C++** code and gradually migrate

### Choose Ada/SPARK if:

- You are building **safety-critical** or **security-critical** software (avionics, defense, railway, nuclear, medical, cryptography)

- You need **formal verification** — mathematical proof that the software satisfies its requirements

- You need to certify to **DO-178C DAL A**, **EN 50128 SIL 4**, or **Common Criteria EAL5+**

- You are working in a domain where Ada compilers, tools, and certification evidence already exist

- You need **hard real-time guarantees** with formal schedulability analysis (Ravenscar/Jorvik)

- You value **40 years of proven deployment** in systems where bugs kill people

### Choose both if:

You are building a complex system with components at different criticality levels — which describes most modern defense and aerospace programs. Use SPARK for the most critical components (flight control, weapon release, safety monitoring) and Rust for the supporting infrastructure (logging, data processing, configuration, network interfaces). This is not hypothetical: AdaCore has integrated Rust interoperability into its toolchain, and several programs are already taking this approach.

The "choose both" answer is increasingly the right one for large systems. A modern combat aircraft has millions of lines of software at different criticality levels: the flight control laws are DAL A (catastrophic failure condition), the mission computer is DAL B or C, the data recording system is DAL D, and the ground support tools might not need certification at all. Using SPARK for the DAL A code, Ada for DAL B/C, and Rust for uncertified supporting tools gives each component the appropriate level of assurance without forcing a single language on the entire system.

This mixed-language approach also addresses the hiring challenge: Rust developers are easier to find than Ada/SPARK developers, so using Rust for the less-critical components reduces the demand for the scarcer Ada/SPARK talent. The most critical code — where formal verification is non-negotiable — is written by the specialists, and the rest of the system benefits from Rust's memory safety without requiring formal proof.

```quote

"Teams that are looking at alternative programming languages have two options today: Ada and Rust. Both languages raise the bar in terms of safety and security compared to C/C++; each has unique strengths." — AdaCore, "Should I Choose Ada, SPARK, or Rust over C/C++?" (2024)

```

---

## What this means for ALB

The [[AdaLogic BASIC]] project sits at the intersection of this debate. The ALB toolchain is built in Ada (using GNAT and `gprbuild`), and the [[ALB Ada backend]] emits Ada source code that can be analyzed by [[SPARK_Ada|SPARK]]'s GNATprove. The ALB team chose Ada not because of nostalgia or institutional mandate but because the same properties that make Ada suitable for avionics — strong typing, range constraints, compile-time safety — make it suitable for a compiler toolchain where correctness matters.

At the same time, the ALB project tracks [[Rust_(programming_language)|Rust]]'s evolution closely. Rust's ecosystem — Cargo, crates.io, the growing embedded community — represents the future of how systems software is distributed and maintained. The two languages are not in conflict for the ALB project; they are complementary tools in a larger engineering strategy.

The memory safety mandate validates a decision the ALB team made years ago: building critical software in a memory-safe language is not a luxury or a compliance checkbox — it is an engineering necessity. Whether that language is Ada, SPARK, or Rust depends on the specific requirements. What matters is that it is not C.

---

## The timeline: a brief history of memory safety awareness

| Year | Event |

|---|---|

| 1988 | Morris Worm exploits buffer overflow in `fingerd` — first major Internet worm |

| 1996 | Aleph One publishes "Smashing the Stack for Fun and Profit" — buffer overflow exploitation goes mainstream |

| 2003 | SQL Slammer worm exploits buffer overflow in Microsoft SQL Server |

| 2014 | Heartbleed (CVE-2014-0160) — buffer over-read in OpenSSL exposes 17% of TLS servers |

| 2015 | Rust 1.0 released (May 15) |

| 2016 | Trident exploit chain targets iOS via memory corruption |

| 2019 | Microsoft reveals 70% of CVEs are memory safety bugs; Google reports same for Chrome |

| 2022 | NSA recommends memory-safe languages (November); Linux kernel accepts Rust (December) |

| 2023 | CISA/FBI/Five Eyes publish "The Case for Memory Safe Roadmaps" (December); Blastpass exploit targets iOS |

| 2024 | White House ONCD publishes memory safety report (February); Android memory safety bugs drop to 24%; CISA finds 52% of critical OSS is memory-unsafe; Ferrocene qualified to ISO 26262 ASIL D |

| 2025 | Android memory safety vulnerabilities fall below 20%; Google reports 1,000x lower vulnerability density in Rust vs C/C++ |

| 2026 | VDC Strategy survey ranks Ada, SPARK, Rust as top three languages for safety/security; C usage in embedded drops to 42.5% |

---

## The verdict: who wins?

**Both win. C and C++ lose.**

That is not a cop-out — it is the honest technical answer. Rust and Ada/SPARK are not competitors in any meaningful sense. They occupy different niches, serve different communities, and provide different guarantees:

- **Rust** wins the **adoption war**. It has the ecosystem, the community, the momentum, and the hiring pool. It is the language that will replace C and C++ in the vast majority of new systems software over the next decade. Google has already proven it works at scale. The Linux kernel has already accepted it. The trajectory is clear.

- **Ada/SPARK** wins the **proof war**. It has the formal verification, the certification heritage, the real-time profiles, and the deployment record. It is the language that will continue to build the software where bugs are not merely expensive but lethal. No other technology can prove functional correctness at industrial scale with forty years of evidence.

- **C and C++** lose. Not immediately — there are hundreds of billions of lines of existing code that cannot be rewritten overnight. But the direction is irreversible. The NSA, the White House, CISA, Google, Microsoft, and the entire European automotive industry have all reached the same conclusion: memory-unsafe languages are a systemic risk, and the era of tolerating that risk is ending.

The real question is not "Ada or Rust?" — it is "How fast can we stop writing new code in C and C++?" Every year of delay costs billions in vulnerability remediation, incident response, and — in the worst cases — lives.

The memory safety mandate is not a fad. It is backed by data (70% of CVEs), by government policy (NSA, White House, CISA, Five Eyes), by industry evidence (Google's 68% reduction in Android), and by the simple reality that the systems we depend on — power grids, hospitals, aircraft, financial networks, military systems — cannot tolerate the bug classes that C and C++ permit.

The future of systems programming is memory-safe. Rust is the language that will bring memory safety to the masses. Ada/SPARK is the language that will continue to guarantee correctness where lives depend on it. Together, they represent the most significant improvement in software safety since structured programming replaced goto. The only debate is which shade of safety you need.

---

## References

[1] NSA, "Software Memory Safety," Cybersecurity Information Sheet, CSI-SOFTWARE-MEMORY-SAFETY, November 2022. media.defense.gov.

[2] White House ONCD, "Back to the Building Blocks: A Path Toward Secure and Measurable Software," February 2024. bidenwhitehouse.archives.gov.

[3] CISA / FBI / ASD ACSC / CCCS, "Exploring Memory Safety in Critical Open Source Projects," June 2024. cisa.gov.

[4] Google Security Blog, "Rust in Android: Move Fast and Fix Things," 2025. blog.google/security.

[5] Microsoft MSRC, "We Need a Safer Systems Programming Language," July 2019. microsoft.com/msrc/blog.

[6] Ferrous Systems, "Ferrocene 24.11.0," ferrocene.dev. ISO 26262, IEC 61508, IEC 62304 qualification.

[7] AdaCore, "Memory Safety in Ada, SPARK, and Rust," whitepaper, November 2024. adacore.com/uploads/papers.

[8] VDC Strategy, "Memory-Safe Languages Offer Protection for Devices and TCO," 2026.

[9] BleepingComputer, "Google sees 68% drop in Android memory safety flaws over 5 years," September 2024.

[10] Embedded Computing Design, "Memory Safety in Ada, SPARK, and Rust," November 2024.

[11] Design News, "Memory-Safe Languages Reduce Development Costs," 2026.

[12] AdaCore, "Should I Choose Ada, SPARK, or Rust over C/C++?" whitepaper, 2024.

[[Category:News]]

[[Category:Programming]]

[[Category:Languages]]