Onboard Flight Software Programming Languages in 2026: C, C++, Rust, and Ada in Practice

Why Language Choice Still Decides Whether a Flight Computer Ships

Walk into any flight software team in 2026 and the language debate is not academic. It decides whether your radiation-tolerant LEON4 board can meet its worst-case execution time (WCET) budget, whether your independent verification and validation (IV&V) partner can trace every branch back to a requirement, and whether the safety authority will accept your code at all. On a cubesat where a stuck watchdog means a dead spacecraft, and on a crewed vehicle where a null pointer dereference could kill people, the choice of C versus C++ versus Rust versus Ada is a systems engineering decision, not a personal preference.

This article is a practitioner's tour of the languages that actually ship on flight computers today, what they are used for, why the incumbents remain entrenched, where the newcomers are gaining ground, and which ones give you the most career leverage if you are trying to break into the field. It is written for engineers who want to know what a real bring-up looks like, not what a marketing deck claims.

We will keep coming back to a few themes: memory safety, worst-case execution time analysis, tooling maturity, certification cost, and heritage. Heritage matters more in space than almost anywhere else, because a language with 30 years of successful missions behind it carries a risk profile no new language can match on day one. But heritage also creates lock-in, and lock-in eventually costs you when the talent pool ages out and hiring becomes impossible.

If you are new to the domain and want a broader career map before diving into language internals, the flight software engineer vs spacecraft software engineer breakdown is a good companion piece. The two roles overlap heavily on languages but diverge on scope.

C: Still the Default, Still the Workhorse

C is the language that shipped on Voyager, on the Space Shuttle general purpose computers (alongside HAL/S), on essentially every JPL deep space mission of the last three decades, on the ISS command and data handling system, and on the overwhelming majority of cubesats flying in 2026. NASA's Core Flight System (cFS), which is arguably the most influential open source flight software framework in existence, is written in C. That single fact tells you most of what you need to know about why C remains dominant.

cFS is not just a codebase, it is a de facto architectural standard. When a new smallsat team at a university or a startup sits down to design their command and data handling (C&DH) stack, the default question is not "what language should we use" but "do we fork cFS or write our own C from scratch." The gravitational pull is enormous. Once you commit to cFS, you commit to C, to a specific message passing model, to a specific table management approach, and to a specific set of application patterns that have flown on Lunar Reconnaissance Orbiter, MMS, GPM, and many more.

The reason C wins on flight computers is not that it is a great language. It is that the tooling is exhaustively mature. GCC and Clang both produce excellent code for SPARC (LEON3/4), PowerPC (RAD750), ARM Cortex-R and Cortex-M, and RISC-V targets. Static analyzers like LDRA, Polyspace, Coverity, and CodeSonar have decades of tuning for C idioms. WCET analysis tools like aiT and RapiTime speak C fluently. Certification credit for tool qualification under DO-178C or ECSS-E-ST-40C is easier to obtain for tools that have already been used on a hundred programs.

MISRA C 2012 (and its 2023 amendments) is the coding standard almost every space program adopts, sometimes with a project-specific deviation list. MISRA restricts C to a safer subset: no dynamic allocation after initialization, no recursion, no goto in most contexts, no side effects in conditional expressions, strict casting rules. If you are hired onto a flight software team as a junior engineer, you will spend a significant fraction of your first year internalizing MISRA rules and arguing with the static analyzer.

The downsides of C are well documented. Buffer overflows, use-after-free bugs, integer overflow, undefined behavior around signed arithmetic and pointer aliasing, and a type system that will happily let you assign a float pointer to an integer with a cast. Every major flight software incident post-mortem includes at least one bug that a memory-safe language would have prevented at compile time. The Mars Polar Lander, Ariane 501, and Boeing Starliner OFT-1 mission elapsed time bug all trace to defects that better tooling might have caught, though not all of them were strictly language-level issues.

C persists because the cost of switching is enormous and the risk of switching, on a program where a single bug can lose a billion dollar asset, is genuinely hard to underwrite.

C++: The Rising Incumbent, Especially at Commercial Space

C++ has quietly become the dominant language at commercial space companies building crewed and semi-autonomous vehicles. SpaceX has been public about using C++ across Dragon and Falcon flight software, running on a Linux-based stack with custom real-time extensions. Blue Origin's New Shepard and New Glenn stacks lean heavily on C++. Rocket Lab's Electron and Neutron avionics use C++ extensively. Even traditionally conservative primes like Lockheed Martin and Northrop Grumman have C++ codebases on newer programs.

The reason is straightforward: C++ gives you real abstractions (classes, templates, RAII, strong typing) while remaining close enough to the metal to hit hard real-time deadlines. On a modern flight computer running RTEMS or Zephyr with a few hundred megabytes of RAM and a multi-core ARM or x86 processor, the overhead of well-written C++ is negligible, and the productivity gain over C is significant.

The C++ used in flight software is not the C++ you write for a game engine. It is a restricted subset, usually aligned with JSF++ (the Joint Strike Fighter coding standard, originally written by Bjarne Stroustrup and colleagues for the F-35) or MISRA C++ 2008 (with 2023 revisions in progress). Common restrictions:

• No dynamic allocation after initialization. Object pools and static allocators only.
• No exceptions. Error codes or std::expected-style return types instead.
• No RTTI (runtime type information). dynamic_cast is banned.
• Templates allowed but with tight restrictions on instantiation depth and code bloat.
• Multiple inheritance forbidden or restricted to interface classes.
• Virtual functions allowed carefully, since they defeat some WCET analysis.

RTEMS, the real-time operating system that flies on many ESA and NASA missions (Solar Orbiter, JUICE, the OSIRIS-REx spacecraft bus, and others), has excellent C++ support. Zephyr, which is increasingly showing up on cubesat avionics and secondary payloads, also supports C++ with a similar restricted profile.

The verification story for C++ is less mature than for C, but it is closing the gap. Polyspace, LDRA, and Parasoft all handle MISRA C++ effectively. Clang's static analyzer and clang-tidy provide free tier coverage that would have been unthinkable a decade ago. The WCET tooling story is weaker (template instantiation and virtual dispatch make static analysis harder) but usable for the subset most flight programs adopt.

If you are learning C++ specifically for flight software work, focus on: RAII patterns for hardware resource management, static polymorphism via CRTP, constexpr for compile-time computation of tables and constants, and the embedded-friendly parts of the standard library (std::array, std::span, std::optional, std::variant). Skip std::vector, std::string, std::map, and anything else that allocates.

Rust: From Curiosity to Serious Contender

In 2020, if you had suggested writing flight software in Rust, most program managers would have laughed. In 2026, it is a live conversation on nearly every new-start program.

The technical case for Rust in flight software is compelling. The borrow checker eliminates entire classes of memory safety bugs at compile time. There is no undefined behavior in safe Rust (unsafe blocks are explicit and auditable). The type system is strong enough to encode invariants that C and C++ leave as runtime checks or comments. Cargo, the build system and package manager, is dramatically better than CMake or Make for most tasks.

Who is actually flying Rust? The picture in 2026 is mixed. Rocket Lab has publicly discussed Rust evaluation for their Ranger satellite bus autonomy subsystems, though the core flight computer remains C++. Several cubesat teams (a growing list from ISAE-SUPAERO, TU Delft, and various U.S. university labs) have flown Rust on secondary experiments and command handlers. Amazon's Kuiper program has referenced Rust in ground segment and simulation, with reported experiments on flight-adjacent components. Ferrous Systems' Ferrocene, a qualified Rust toolchain, achieved ISO 26262 ASIL D and IEC 61508 SIL 4 qualification in 2024, which opened the door for safety-critical adoption more broadly.

The MISRA C++ committee spun up a MISRA Rust working group in 2023, and by 2026 there is a working draft of a Rust coding standard for safety-related systems. The Ferrocene Language Specification, first published in 2023, is the closest thing Rust has to an ISO standard and is being referenced in tool qualification packages for space applications.

The barriers to broader Rust adoption in flight software are real:

• Target support. Rust's tier 1 targets are common desktop and server architectures. SPARC (LEON), PowerPC (RAD750), and some Cortex-R variants are tier 2 or tier 3, meaning the toolchain works but is not automatically tested by the Rust project. Ferrocene is closing this gap for specific targets.
• WCET tooling. aiT and similar tools do not have first-class Rust support in 2026. You can analyze the generated machine code, but source-level attribution is weaker.
• Async and allocation. Most flight software Rust in 2026 is no_std with heapless data structures. This works but constrains what libraries you can pull in.
• Talent. The pool of engineers who know both Rust and DO-178C or ECSS-E-ST-40C is small. Programs that adopt Rust are training their teams on the job.

If you are early in your career and want optionality, Rust is the highest-leverage new language to learn in 2026 for space and adjacent safety-critical work. The spacecraft software engineer program covers Rust alongside C and C++ specifically because we see the hiring shift happening at Rocket Lab, Astranis, K2 Space, and a growing list of European new-space companies.

Ada and SPARK: The Quiet Continuity

Ada is the language most outsiders assume is dead. It is not. Ada 2012 and Ada 2022 continue to fly on active programs, and the SPARK subset (a formally verifiable Ada) is arguably the most rigorous option available for safety-critical code.

The Boeing 787 flight control system is written in Ada. The Airbus A350 uses Ada extensively. The James Webb Space Telescope's flight software has significant Ada content. The Ariane 6 launcher includes Ada modules. ESA has maintained Ada as an accepted language throughout ECSS-E-ST-40C, and several ESA-led missions (BepiColombo attitude control, Sentinel series ground and flight components) include Ada.

Why does Ada persist? Because it was designed from day one for safety-critical embedded work. Strong typing (an Ada Integer is not a Float and never will be without an explicit conversion), range-constrained subtypes, tasking as a first class concept, and package-level encapsulation that predates most modern module systems. SPARK adds formal verification: you can prove absence of runtime errors (no overflow, no division by zero, no out-of-bounds access) at compile time, and you can prove functional correctness for specified properties.

AdaCore's GNAT Pro toolchain has been qualified for DO-178C at all design assurance levels and for ECSS categories. The tool cost is significant, but so is the certification credit you get in return. For programs where the cost of a single defect is measured in lost billions or lost lives, that math often works out in Ada's favor.

The career reality for Ada in 2026 is that demand is stable, supply is thin, and salaries are consequently high for experienced practitioners. If you learn Ada and SPARK, you will not have the volume of job openings that C or C++ offers, but the roles you find will pay well and last long. Airbus, Boeing, Thales Alenia Space, Ariane Group, and several U.S. defense primes all keep active Ada teams.

Learning Ada as a supplement to C or C++ is a strong move. The mental model shift (thinking in terms of types and contracts rather than pointers and casts) will improve your C++ and Rust code as well.

Assembly: Small, Critical, Unavoidable

Nobody writes flight software in assembly anymore, but every flight software project has some assembly in it.

Where assembly still lives in 2026:

• Boot loaders. The first few kilobytes that run after power-on reset, before RAM is initialized and the C runtime is available, are almost always hand-written assembly for the specific processor.
• Interrupt service routine entry and exit. On some targets, the compiler-generated ISR prologue is not fast enough or not deterministic enough, so critical ISRs use hand-tuned assembly wrappers.
• Context switching. The kernel-level primitive that saves one task's registers and restores another's is inherently architecture-specific and usually written in assembly.
• Cache and MMU management. Instructions like SPARC's flush, PowerPC's dcbf, or ARM's DSB and ISB barriers are wrapped in inline assembly or intrinsic calls.
• Radiation mitigation. Triple modular redundancy (TMR) voting logic, EDAC (error detection and correction) scrubbing loops, and single-event upset (SEU) recovery code sometimes drop to assembly for determinism and predictable timing.

The assembly you write is architecture specific. SPARC V8 (LEON3) and SPARC V9 (LEON4/LEON5) have their own idioms around register windows. PowerPC on the RAD750 and RAD5545 has its own memory model. ARM Cortex-R5 (increasingly common on new-space flight computers) is the friendliest modern option because ARM's documentation is excellent and the ecosystem is large.

You do not need to become an assembly expert to work in flight software, but you need enough fluency to read a disassembly listing when a bug turns out to be in the compiler's code generation, or when a WCET analysis flags a specific instruction sequence. If you cannot read the assembly output of your C or C++ or Rust code, you cannot fully diagnose real-time failures.

Real-Time Operating Systems and How They Shape Language Choice

The RTOS you fly on constrains the language you use more than most engineers realize. The RTOS landscape in 2026 for flight computers is roughly:

• RTEMS: Open source, mature, POSIX-compatible, excellent C and C++ support, used across ESA and NASA. If you are on RTEMS, you are almost certainly writing C or C++.
• VxWorks: Wind River's commercial RTOS, dominant in defense and aviation, used on Mars rovers (Spirit, Opportunity, Curiosity, Perseverance), Orion, and many others. Strong C and C++, some Ada support.
• Zephyr: Linux Foundation project, increasingly common on cubesats and secondary payloads, C-first with growing C++ support and experimental Rust bindings.
• FreeRTOS and SafeRTOS: FreeRTOS on cubesats, SafeRTOS (a certified variant) on higher assurance systems, both C-centric.
• Bare metal: A surprising fraction of small satellites run without an RTOS at all, with a single main loop and interrupts. Usually C, sometimes Rust in newer designs.
• Linux with real-time patches (PREEMPT_RT): SpaceX's approach on Dragon and Falcon, and increasingly common on non-safety-critical spacecraft compute nodes.

The critical implication: if you want to work on legacy flagship missions, learn RTEMS and C. If you want to work at SpaceX or a new-space startup, learn Linux and C++. If you want to work on the next generation of high-assurance systems, add Rust and Ferrocene. The space mission software development lifecycle piece walks through how RTOS choice ripples through the entire V-model, from requirements to acceptance.

Certification, Coding Standards, and Why Tools Cost More Than Salaries

One of the shocks for engineers moving from web or general embedded work into flight software is how expensive the tooling is. A single seat of a qualified static analyzer can cost tens of thousands of dollars per year. A qualified compiler license (GNAT Pro, IAR, Green Hills) is similar. A DO-178C tool qualification package for a custom tool can consume months of engineering time.

The reason is not vendor greed. It is that the tool itself has to be trusted. Under DO-178C, if you use a tool to eliminate or reduce a verification activity (a compiler that eliminates the need for object code review, or a static analyzer that eliminates the need for certain manual code inspections), the tool has to be qualified to the same level as the code it produces. Tool qualification requires evidence: requirements, design, verification, and often the tool developer's own DO-330 compliance package.

Coding standards align with languages roughly as follows in 2026:

• C: MISRA C 2012 (with 2023 amendments), CERT C, JPL Institutional Coding Standard for C, or a project-tailored subset.
• C++: MISRA C++ 2008 (2023 draft in circulation), JSF++, AUTOSAR C++14 (which is being folded back into MISRA), or project-tailored.
• Rust: MISRA Rust (draft), Ferrocene Language Specification, plus internal project standards. Still maturing.
• Ada: Ada 2012 or Ada 2022, with SPARK subset where formal proof is required. AdaCore's High-Integrity Ada profile.

The certification frameworks that matter for space are ECSS-E-ST-40C and ECSS-Q-ST-80C (European), NPR 7150.2 (NASA), and DO-178C (aviation, but often used as a reference for crewed space vehicles). Each specifies design assurance levels and required verification activities that scale with the criticality of the software.

When you plan verification for real, the spacecraft software testing and verification treatment goes deeper into structural coverage, requirements-based testing, and independence of verification.

Memory Safety, WCET, and the Real Language Tradeoffs

The most honest way to compare these languages is on the tradeoffs that actually matter in flight. Here is how they stack up in 2026:

Memory safety at compile time: Rust and SPARK/Ada win decisively. C++ with modern practices and strong static analysis gets you most of the way. C, even with MISRA, still allows classes of bugs that the other languages prevent by construction.

Worst-case execution time analysis: C wins by tooling maturity. Ada is close. C++ works if you restrict the subset. Rust is workable but the tooling is behind.

Certification cost: Ada with GNAT Pro has the lowest per-project certification cost for high-assurance work because so much is pre-qualified. C is second because of tool maturity. C++ is more expensive due to language complexity. Rust is currently the most expensive because you are often qualifying your own tools.

Talent availability: C++ has the largest pool in 2026 among engineers under 40. C has a large pool that skews older. Rust has a small but rapidly growing pool. Ada has a small pool that skews older and is not being replenished fast enough.

Interoperability with existing flight heritage: C wins by an enormous margin. Everything talks to C. C++ and Rust both have good C FFI stories. Ada's C interop is workable but requires more care.

Concurrency model: Ada's tasking model is the most mature by design. Rust's ownership model is the safest for shared-state concurrency. C++ has std::thread and std::atomic but no borrow checker to protect you. C has POSIX threads and manual discipline.

A practical example: on a spacecraft attitude control subsystem, the sensor read loop, the estimator, and the actuator command loop all run at different rates and share state. In Ada, you would use protected objects and rendezvous. In Rust, you would use channels or Arc<Mutex<>> in std, or heapless queues in no_std. In C or C++, you would use RTOS mailboxes or semaphores and rely on code review to catch race conditions. The Ada and Rust versions are structurally safer.

Learning Paths: Where to Start Based on Where You Want to Work

If you are trying to break into flight software in 2026, the language you learn first should be shaped by where you want to work and what you can find internships or entry roles at.

For NASA and NASA prime contractors (JPL, GSFC, APL, Ball Aerospace, Lockheed Martin, Northrop Grumman civil space): learn C first, learn cFS second, learn C++ third. The heritage codebases are C-heavy and cFS is the framework you will actually touch on your first job.

For SpaceX, Rocket Lab, Blue Origin, Astranis, and most U.S. new-space: learn C++ first, learn Linux real-time development second, learn Python for tooling and test third. Rust as a fourth language is increasingly a differentiator.

For ESA and European primes (Airbus Defence and Space, Thales Alenia Space, OHB, ArianeGroup): learn C and C++ for spacecraft bus work, learn Ada for launcher and high-assurance components. RTEMS familiarity is a strong signal.

For defense primes and classified work: learn C and Ada, get comfortable with DO-178C processes, and prepare for a security clearance timeline.

A reasonable 12-month self-study plan looks like this:

1. Months 1-3: Solidify C, read MISRA C 2012, work through the cFS training material NASA publishes openly.
2. Months 4-6: Add C++, focus on the embedded subset, build a small flight-software-like project on a Cortex-M4 or Cortex-R5 dev board.
3. Months 7-9: Add Rust, work through the Embedded Rust book, build the same kind of small project in no_std Rust.
4. Months 10-12: Add Ada and SPARK basics through AdaCore's free Learn.AdaCore materials. Try to prove absence of runtime errors on one of your earlier projects re-implemented in SPARK.

During the same year, you should also touch simulation tools, since flight software is meaningless without a simulator. The astrodynamics software tools like GMAT, STK, and Poliastro piece is a useful primer if you have never touched mission-level simulation.

Interview Signals and What Hiring Managers Actually Look For

When hiring managers at flight software teams evaluate junior candidates in 2026, language proficiency is table stakes. The signals that actually differentiate candidates are:

• Can you read a datasheet and write a driver? A candidate who can bring up a SPI or I2C peripheral from the datasheet, in any language, is more valuable than one who can quote MISRA rules but has never touched hardware.
• Do you understand what happens between main() and reset? Bootloaders, linker scripts, startup files, and interrupt vector tables. If these are mysterious, you are not ready for flight software.
• Can you reason about worst-case behavior? What happens if this interrupt fires during that critical section? What if the sensor stops responding? What if a cosmic ray flips a bit in the stack pointer?
• Do you write testable code? Not just unit-tested code. Code that can be exercised in a hardware-in-the-loop simulator with fault injection.
• Do you communicate clearly in writing? Flight software is a written culture. Change requests, review comments, and anomaly reports are all written artifacts that outlive the engineers who wrote them.

A candidate who is decent in C and C++ but demonstrates all five of those signals will beat a Rust or Ada expert who cannot. Language is a tool. The engineering judgment around it is the actual skill.

If you are preparing for interviews specifically, the guide on SpaceX, Blue Origin, and Rocket Lab software jobs covers what each of those teams typically probes, and how to become a spacecraft software engineer covers the broader trajectory including internships and portfolio projects.

Failure Modes: When Language Choice Actually Caused the Bug

It is worth grounding this discussion in real incidents, because otherwise it drifts into ideology.

Ariane 501 (1996): An unhandled overflow in an Ada floating-point-to-integer conversion, in a horizontal velocity variable inherited from Ariane 4, caused the inertial reference system to fail. The direct language-level cause was that the overflow was not caught, but the deeper cause was reusing a module without re-validating its input range assumptions. Ada actually caught the overflow via a runtime check. The bug was that the exception was not handled and the backup unit had the same code. This is a case where language safety worked as designed, but system design defeated it.

Mars Climate Orbiter (1999): Unit mismatch between metric and imperial in navigation data. Not a language-level issue. A stronger type system (Ada's dimensioned types, or C++ with a units library, or Rust with newtype patterns) would have caught it at compile time.

Mars Polar Lander (1999): A spurious signal from the landing legs was interpreted as touchdown, cutting off the descent engines early. C code, no dimension checking, no state machine invariants enforced by the language.

Toyota unintended acceleration (2010s, not space but instructive): Investigation found extensive violations of MISRA C, uncontrolled recursion, and stack overflow risk. This was the wake-up call that convinced many programs MISRA compliance was not optional.

Boeing 787 lithium-ion battery (2013): Not directly a software issue but the software response contributed. Ada code performed correctly but the sensor model was incomplete.

Boeing Starliner OFT-1 (2019): Mission elapsed timer initialization pulled the wrong value from the Atlas V, causing the vehicle to think it was 11 hours further into the mission than it was. Software behaved as coded. The defect was in interface control and integration testing, not in the language. A stronger type or invariant system might have caught the plausibility check, but that is speculative.

The pattern across these incidents: language-level memory safety would have prevented some bugs. It would not have prevented most of the famous ones. Systems engineering, requirements validation, and integration testing prevent more incidents than any language feature. This is why hiring managers value engineering judgment over language religion.

Where This Is All Heading: Predictions for 2027 and Beyond

A few reasonable predictions if current trends continue:

1. Rust will fly on a primary flight computer on a commercial mission before 2028. Rocket Lab, Astranis, or a European new-space startup is the most likely first mover.
2. MISRA Rust will be a published standard by 2027 and adopted on at least one flagship program by 2029.
3. C will remain the majority language on flight computers in absolute terms through 2030 because of installed base and cFS gravity, but its share of new-start programs will drop below 50 percent by 2028.
4. C++ will be the dominant language on new commercial space programs through 2030, gradually ceding ground to Rust after 2028.
5. Ada will not grow but will not shrink either. It will remain the language of choice for the highest assurance work, and salaries for experienced Ada engineers will continue rising because supply is not replenishing.
6. AI-assisted code generation will change how flight software is written, but not what it is written in. Copilot-style tools will accelerate C, C++, and Rust equally, and the verification burden will actually increase because generated code needs the same level of scrutiny.

The engineers who position themselves best for this decade are those who are polyglot within the flight software family: strong in C and C++, competent in Rust, familiar with Ada, and fluent in the systems context around all of them.

About Refonte Learning

Refonte Learning is the training arm of Refonte Infini Infiniment Grand, a French SAS (SIREN 949 841 605, verifiable at https://data.inpi.fr/entreprises/949841605), with an operational office at 1 Poulton Close, Dover, Kent, United Kingdom, CT17 0HL. Our space software curriculum is built by engineers who have shipped flight software on operational missions, and it covers the languages, tools, and processes described in this article in hands-on depth.

If you are ready to move from reading about flight software to writing it, the Refonte Learning spacecraft software engineer program pairs C, C++, Rust, and Ada training with cFS, RTEMS, and mission simulation work, and connects you with internship opportunities at organizations building the next generation of spacecraft. Language choice is a tool. The engineering judgment we build around it is the career.