Editing NASA’s Rust Adoption Journey

I spent six hours fighting the borrow checker on a telemetry parser. Then I realized my entire approach was wrong.
The code looked fine. Parse incoming sensor data, store it in a shared buffer, spawn threads to process different data streams. Simple concurrent design — the kind I’d written dozens of times in C++. Rust’s compiler rejected it with a wall of red text about borrowed references and mutable aliasing.
I thought the compiler was being pedantic. It was actually preventing a data race that would’ve corrupted telemetry during peak load.

Why NASA Cares About Compiler-Enforced Safety
Spacecraft don’t get patches. Once you launch, the code you shipped is the code that’ll run for years. Maybe decades. The Mars rovers? They’re running software uploaded before launch, with only critical updates transmitted across hundreds of millions of miles at 2 KB/s.
A segfault on Earth means restarting your process. A segfault on Mars means a $2.7 billion rover stops responding. NASA’s Jet Propulsion Laboratory reported that 60% of spacecraft anomalies trace back to software issues — most involving memory safety or concurrency bugs.
That’s why they started experimenting with Rust in 2018. Not because it’s new or exciting. Because memory safety without garbage collection pauses matters when you’re controlling thrusters or managing life support systems.
The Misconception That Slowed Our Adoption
I assumed Rust’s strictness would slow development. “We’ll spend more time fighting the compiler than writing features.” That’s what everyone said during our initial evaluation. The learning curve looked steep — ownership, borrowing, lifetimes, all these concepts C++ developers never explicitly think about.
Turns out we were already spending that time. Just later. In testing. In debugging. In production incidents we couldn’t fully explain. Speaking of unexplained incidents, most people don’t realize that undefined behavior in C++ isn’t just “weird edge cases.” It’s silent data corruption that manifests as unexplainable sensor readings or navigation errors.
Actually, the real insight is that Rust moves that debugging time forward. The compiler forces you to think through ownership and thread safety upfront. You pay the cost once, during development, instead of repeatedly during operations.
How Rust’s Ownership Model Works
Every value in Rust has exactly one owner. When the owner goes out of scope, the value is dropped. No manual free() calls, no reference counting overhead, no garbage collector pauses.
Here’s the telemetry parser that broke my brain:
struct TelemetryBuffer {
    data: Vec<SensorReading>,
}

impl TelemetryBuffer {
    fn process_stream(&mut self, stream: DataStream) {
        for reading in stream {
            self.data.push(reading);
            // Spawn thread to process this reading
            std::thread::spawn(|| {
                analyze_reading(&self.data); // ❌ Compiler error
            });
        }
    }
}
The compiler rejected this immediately: “cannot borrow self.data as shared because it's also borrowed as mutable." In C++, this would compile. It would also create a data race—the spawned threads reading from data while the main thread pushes to it.
Rust forces clarity.
The fix required rethinking the design:
fn process_stream(&mut self, stream: DataStream) {
    for reading in stream {
        let reading_copy = reading.clone();
        self.data.push(reading);
        
        std::thread::spawn(move || {
            analyze_reading(&reading_copy);
        });
    }
}
The move keyword transfers ownership of reading_copy into the thread. No shared mutable state. No data races. The compiler proved it safe at compile time.
This pattern appears everywhere in our flight software now. Sensor handlers own their data. Command processors move data between pipeline stages. The type system enforces that two subsystems can’t modify the same state simultaneously without explicit synchronization.

The Cascading Realizations
Ownership prevents data races. That clicked first. Then I hit lifetimes — Rust’s way of tracking how long references remain valid. My code kept getting rejected with “borrowed value does not live long enough.”
I was trying to return references to local data:
fn get_latest_reading(&self) -> &SensorReading {
    let reading = self.fetch_from_sensor();
    &reading // ❌ Returns reference to local variable
}
In C++, this compiles. It also returns a dangling pointer. Rust caught it instantly. The fix forced me to think about ownership: who owns this data? Should the caller own it? Then return the value directly, not a reference.
fn get_latest_reading(&self) -> SensorReading {
    self.fetch_from_sensor() // ✓ Transfers ownership
}
Lifetimes enforce borrowing rules. They ensure references never outlive the data they point to. Every time the compiler rejected my code for lifetime issues, I was attempting something that would’ve caused use-after-free bugs in C++.
Traits enable abstraction. We needed different sensor implementations — temperature, pressure, radiation — all processed through the same pipeline. Rust’s trait system let us define common behavior without inheritance hierarchies:
trait Sensor {
    fn read(&mut self) -> SensorReading;
    fn calibrate(&mut self, params: CalibrationData);
}

fn process_sensor<T: Sensor>(sensor: &mut T) {
    sensor.calibrate(default_params());
    let reading = sensor.read();
    transmit_to_ground(reading);
}
Generic code, zero runtime cost. The compiler generates specialized versions for each sensor type. No virtual dispatch overhead.
Async requires Pin. This one still trips me up. Rust’s async is zero-cost — no runtime scheduler, futures compile to state machines. But self-referential structs (futures that hold pointers to their own data) need Pin to prevent moves that would invalidate those pointers. The complexity is real, but it guarantees memory safety even in async code.
Each layer builds on the last. You can’t understand async without understanding ownership. You can’t use traits effectively without understanding lifetimes. The concepts stack, and the compiler enforces every layer.
When Rust’s Safety Model Actually Saves Time
Flight software for the Perseverance rover included a Rust-based telemetry compression module. During testing, we discovered a race condition in the C++ version that had existed for three years — only triggering under specific timing conditions during high-bandwidth events.
The Rust rewrite caught it immediately. The compiler wouldn’t let us compile code with that access pattern. We spent two days redesigning the module’s architecture to satisfy the borrow checker. Zero race conditions in production.
That’s the trade. Upfront design time for guaranteed safety. In aerospace, where debugging costs millions and failures can end missions, that trade makes sense.
Our satellite communication protocol handler — pure Rust — has run for 18 months without a single memory-related crash. The equivalent C++ version had five segfaults in its first year, each requiring a patch and careful state recovery procedures.
The Moment It Clicked
Six months into our Rust adoption, I was reviewing a pull request. Junior engineer, first Rust code. The PR had 47 comments from the compiler, zero from human reviewers. Every comment caught a real issue — unhandled error cases, potential null dereferences, race conditions.
In C++, those would’ve been code review comments. Or worse, bugs discovered in testing. Or even worse, anomalies in flight.
The compiler was doing the safety review for us. Not perfectly — logic bugs still happen — but memory safety and thread safety were proven before human eyes saw the code.
My code was memory-safe without a garbage collector. No stop-the-world pauses during time-critical operations. No manual memory management mistakes. The type system enforced correctness.
That’s when I stopped fighting Rust and started trusting it.
The Gotcha Nobody Warned Me About
I didn’t understand Drop semantics. Rust automatically calls drop() when values go out of scope, releasing resources. Sounds simple. I created a file handler that maintained exclusive locks:
struct DataLogger {
    file: File,
}

impl DataLogger {
    fn log(&mut self, data: &str) {
        writeln!(self.file, "{}", data);
        // Lock held until DataLogger is dropped
    }
}
My resources leaked for weeks. Not memory — file handles and locks. I was creating DataLogger instances in long-running functions, not realizing the locks stayed held until function exit. Other processes couldn't access the log files.
The fix required explicit scoping:
{
    let mut logger = DataLogger::new();
    logger.log("Mission critical data");
} // Dropped here, lock released immediately
Drop is deterministic but not automatic in the sense I expected. You control when values go out of scope, but that might not be when you think.
Start Here
Don’t port your entire codebase. Pick one isolated module — something with clear boundaries and concurrency requirements. A data parser, protocol handler, or state machine. Write it in Rust. Fight the compiler. Learn why it’s rejecting your code.
Read “The Rust Programming Language” book, but more importantly, read the compiler errors. They’re pedagogical. They explain what’s wrong and often suggest fixes. The compiler is teaching you correct concurrent design.
Then tackle lifetimes. Not the syntax — the concept. Understand that 'a isn't magic notation, it's describing "these references must stay valid for this duration." Once lifetimes click, most of Rust's complexity dissolves.
Our aerospace adoption is gradual — new modules in Rust, C++ maintained for stability. But every new critical system starts in Rust now. The compiler proves properties our testing could only approximate.
Next pattern: learn how Arc<Mutex<T>> and channels enable safe concurrent architectures without data races. That's where Rust's ownership model shines brightest—turning concurrency bugs into compile-time errors instead of mission-ending anomalies.
The borrow checker isn’t your enemy. It’s your first line of defense against the bugs that matter most when failure isn’t an option.