Ada vs Rust: The Memory Safety Showdown
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.
The government has mandated memory safety. Rust and Ada/SPARK are the only serious contenders — one born in Mozilla's research labs, the other forged in the Pentagon's Cold War software crisis. Here is how they actually compare when the compiler hits the metal.
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 |
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 |
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].
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'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:
- You can have either one mutable reference or any number of immutable references to a value, but not both simultaneously.
- 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
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 and 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
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
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 |
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
The 30-million-line problem
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.
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'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'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.