The Argument
for Rust

To understand why Rust exists, you need to understand what computing's deepest, most persistent problem actually is. It is not algorithmic complexity. It is not network latency. It is not database design. It is memory — specifically, the question of who owns a piece of memory, who is allowed to read it, who is allowed to write it, and when it should be released.

This problem has been causing catastrophic failures since the 1970s. A 2019 analysis by Microsoft found that approximately 70% of the CVEs they assigned over the previous twelve years were memory safety bugs. Google's Project Zero team reports similar numbers for Chrome. The NSA published guidance in 2022 recommending that organisations transition to memory-safe languages. These are not theoretical concerns — they are buffer overflows in production firewalls, use-after-free vulnerabilities in browsers, and null pointer dereferences in ISP routing daemons. The attacks that compromised infrastructure you have personally managed in East Africa almost certainly exploited a memory safety bug somewhere in the chain.

Memory management is hard because it involves time. A piece of data is allocated at one moment. It may be referenced by many different parts of the program simultaneously. It must be released exactly once — not before all references to it are finished (use-after-free), and not released and then released again (double-free), and not held forever when nothing needs it any more (memory leak). Getting this right across a large codebase, across multiple threads, across code written by multiple engineers over multiple years, is genuinely difficult. The programming languages of the world have tried three distinct approaches to this problem, and each has a cost.

The ownership approach is Rust's core contribution to computing. It is not a new idea — the theory comes from linear type systems in academic computer science, specifically from work by Philip Wadler and others in the 1990s. What is new is making it practical, ergonomic, and fast enough for systems programming. The borrow checker — the compiler component that enforces ownership rules — is the most important thing in the Rust toolchain. Chapter 2 is entirely devoted to understanding it.

You have written C. Or you have worked with systems written in C — routers, switches, embedded controllers. You know how it feels to debug a segmentation fault that only appears under load on a production system at 3am. Let us be precise about what C's failure modes are, because understanding them makes Rust's design choices legible.

C arrays are simply memory addresses. When you write arr[10] and arr has 8 elements, C will happily compute the address, add the offset, and write or read from whatever happens to be at that memory location. There is no bounds checking at runtime unless you add it yourself. There is certainly no compile-time check. The Morris Worm in 1988 exploited a buffer overflow in fingerd. Heartbleed in 2014 — which affected HTTPS servers globally, including those serving African banking systems — was a buffer over-read in OpenSSL. These were not bugs in obscure edge-case code. They were in core infrastructure written by experienced engineers.

In C, when you call free(ptr), the memory is returned to the allocator. The pointer variable itself still holds the same address. Nothing in C prevents you from reading or writing through that pointer after the free. This is a use-after-free vulnerability. If an attacker can cause you to free a buffer and then use it again, they can often control what the reallocated memory contains — and therefore control what your program reads and executes. In C++, this is also possible through smart pointers if you are not careful with shared_ptr cycles and object lifetime.

// This compiles. It runs. It is undefined behaviour.
// What it does depends on the allocator, the OS, the moon phase.
char *buf = malloc(256);
strcpy(buf, "Sprint Group NOC");
free(buf);
// ... some code later ...
printf("%s\n", buf);  // Use after free. May work. May crash. May be exploited.

let s = String::from("Sprint Group NOC");
drop(s);  // Explicitly drop s — memory is freed here
println!("{}", s);  // COMPILE ERROR: use of moved value: `s`
// error[E0382]: borrow of moved value: `s`
// The program does not compile. The bug cannot ship.

The Rust compiler's error is not a warning. It is a hard refusal. The program does not compile. The bug cannot exist in a Rust binary because the compiler will not produce the binary. This is the fundamental difference. In C, correctness depends on programmer discipline applied consistently over the entire lifetime of the codebase by every engineer who ever touches it. In Rust, correctness is mechanically verified on every build.

In C, if two threads simultaneously read and write the same memory location without synchronisation, you have a data race. Data races are undefined behaviour in C — the compiler is allowed to assume they do not happen, and will optimise your code in ways that make catastrophic sense from a correctness perspective but are completely unexpected. Data races in multi-threaded C code are notoriously difficult to reproduce and nearly impossible to find with code review alone. Tools like ThreadSanitizer can find them, but only at runtime, and only in code paths that execute during testing.

In Rust, data races are impossible. The ownership and borrowing rules make it impossible to have two simultaneous mutable references to the same data — from the same thread or from different threads. If you try to share mutable data between threads without proper synchronisation primitives (Mutex, RwLock, atomic operations), the compiler refuses to compile the code. Thread safety is a compile-time guarantee. This is why Rust's standard library types are documented with Send and Sync marker traits — the compiler tracks which types are safe to send between threads and which can be shared between them.

If C is so dangerous, why not just use a garbage-collected language everywhere? Python, Java, Go — they are all memory-safe. They are all far more productive to write in than C. What is the actual cost of a garbage collector, and why does that cost matter for the work in this book?

A garbage collector runs periodically to identify and free unreachable memory. The most common modern collectors (like JVM's G1GC, or Python's cyclic GC) require stop-the-world pauses — moments where all your application threads stop so the collector can safely inspect and modify the heap. In Go's concurrent collector, these pauses are sub-millisecond for most workloads. In CPython, the GIL means only one thread runs at a time anyway. In Java, major GC pauses of tens or hundreds of milliseconds are possible under load.

For a web API serving ISP customers, a 50ms GC pause means a 50ms tail latency spike on that request. Users notice latency above 100ms. For a network monitoring system that needs to detect and alert on BGP session drops within seconds, a periodic 100ms freeze is not catastrophic. But consider your Pico's motor controller: if you needed precise PWM timing and a GC pause stopped your control loop for 50ms, the motor would behave erratically. Real-time embedded systems cannot tolerate non-deterministic pauses. This is the first and most important reason there is no garbage-collected language in the embedded world.

A garbage collector requires overhead — the collector's own heap metadata, the objects needed to track reference counts or object graphs, the headroom in the heap to allow allocation between collection cycles. The JVM baseline for a minimal application is 50–100MB of RAM. Python's base memory footprint is 20–50MB. Go is more efficient but still requires several megabytes.

Your Pico 2 has 520KB of RAM. Total. All of it. That includes your stack, your global variables, your driver state, your Embassy task arenas, and anything else your application allocates. A Go runtime would consume all available memory and more before you wrote a single line of application code. Garbage collection is architecturally incompatible with the embedded microcontroller world.

Garbage-collected languages depend on a runtime — a layer of code that initialises the heap, starts the collector, provides system services. That runtime requires an operating system to exist. The JVM calls OS APIs to allocate virtual memory. CPython calls malloc. Go's runtime needs OS threads. On the RP2350 with no OS, none of these runtimes can run. The only languages that can run on bare metal are those that can operate without an OS: C, C++, Ada, and Rust.

Of these, only Rust provides memory safety guarantees at compile time. This is not a close call. If you want memory safety on bare metal, Rust is currently the only practical choice.

Bjarne Stroustrup, the creator of C++, articulated the zero-cost abstraction principle: "What you don't use, you don't pay for. And further: What you do use, you couldn't hand-code any better." Rust takes this seriously — more seriously than C++ does, and with stronger guarantees.

In Java or Python, generic types (templates, type parameters) are resolved at runtime through a mechanism called type erasure (Java) or dynamic dispatch (Python). This means that a List<String> and a List<Integer> are the same class at runtime — the type information is lost. Generic method calls go through virtual dispatch, which requires a pointer indirection and prevents inlining.

In Rust, generics are resolved at compile time through monomorphisation. When you write a generic function fn process<T: Display>(item: T), the compiler generates a separate, concrete version of that function for every type T you actually use. If you call it with a u32 and a String, the compiler generates process_u32 and process_string — both fully concrete, both inlinable, both with no runtime type overhead. The abstraction costs nothing at runtime because it is resolved before runtime exists.

In most languages, using higher-order functions (map, filter, fold) instead of for-loops has a performance cost — function call overhead, closure allocation, virtual dispatch. Idiomatic Rust code uses iterators heavily, and yet iterator chains in Rust compile to the same assembly as hand-written loops — often to better assembly, because the optimizer can see the full computation and apply transformations that are not possible when the code is written as explicit loops with mutable variables.

// Iterator version — idiomatic, readable, zero-cost
let sum: u32 = (0..=100)
    .filter(|n| n % 2 == 0)
    .map(|n| n * n)
    .sum();

// Loop version — the compiler generates identical assembly for both
let mut sum: u32 = 0;
for n in 0..=100u32 {
    if n % 2 == 0 {
        sum += n * n;
    }
}

// The compiler sees through the abstraction. No allocation. No function pointers.
// In --release mode, both produce the same tight loop in assembly.

This is where Rust does something remarkable that no other language does. In Node.js, every async function creates a Promise object on the heap. In Python, every coroutine is a heap-allocated object. In Go, every goroutine has a small but non-zero heap-allocated stack. These allocations are cheap individually but accumulate, require GC, and require a heap to exist at all.

In Rust, an async function compiles to a state machine. The compiler analyses the function's await points, identifies all the variables that must survive across those points, and generates a struct containing exactly those variables. The struct is sized at compile time. It can be allocated on the stack, in a static memory region, or anywhere the programmer chooses — without a heap allocator. This is how Embassy runs async code on the RP2350 with no heap, no malloc, and no garbage collector: every async task is a fixed-size state machine allocated in a static array at startup.

Before learning a new language, it is reasonable to ask whether it has been proven in production at scale. The answer for Rust is unambiguous: yes, at some of the most demanding scale and reliability requirements in the industry.

The pattern is consistent: organisations with the highest reliability and security requirements and the engineering resources to evaluate alternatives carefully are choosing Rust. This is not fashion. It is the result of cost-benefit analysis by engineers who have been burned by memory safety bugs in C and C++, found GC latency unacceptable, and needed something that combined both worlds.

The annual Stack Overflow Developer Survey has found Rust to be the "most loved" language for seven consecutive years through 2024. This survey metric measures the percentage of developers currently using a language who wish to continue using it. The number for Rust has been above 85% every year — meaning the overwhelming majority of people who have used Rust want to keep using it. Compare this to languages that people use because they have to (PHP, Java) versus languages people use because they want to. Rust is decisively in the latter category.

The Rust Foundation — an independent organisation supporting Rust's development — has members including Google, Microsoft, Amazon, Huawei, Mozilla, and Samsung. This is not a language at risk of disappearing. It is infrastructure at a level that makes it as stable a bet as any language in production today.

Embedded systems have traditionally been the domain of C — and for good reason. C gives you direct memory access, predictable code size, no runtime overhead, and a fifty-year history of toolchain maturity. When you program a microcontroller in C, you know exactly what the compiled binary will do and how much flash it will occupy. These properties are valuable.

The problems with C in embedded systems are the same problems with C everywhere, but they are worse. In a server, a memory corruption bug might cause a service restart or a security breach — both bad, but recoverable. In an embedded system controlling physical hardware, a memory corruption bug can cause a motor to run at full speed when the command was stop, or a valve to open when it should close, or a safety system to disable when it should activate. The consequences are not just data loss but physical damage and injury.

Embedded Rust has matured substantially since 2018. The key components are now stable and production-ready:

The HAL trait system defines hardware abstraction layer traits — interfaces for GPIO, SPI, I2C, UART, PWM — that peripheral drivers can be written against. A driver written against the embedded-hal traits works with any microcontroller that implements those traits. This is a level of portability that does not exist in the C embedded ecosystem, where drivers are almost always chip-specific.

Embassy is the async embedded framework we will use throughout this book. It provides an async executor that runs on bare metal, HAL implementations for the RP2350 (and many other chips), timer abstractions, synchronisation primitives, and networking stacks. It is not a toy — it is used in production medical devices, industrial controllers, and aerospace systems.

defmt is a logging framework optimised for embedded systems. Instead of formatting strings on the microcontroller (expensive, requiring heap allocation), defmt sends compact binary representations over RTT (Real-Time Transfer) and formats them on the host machine. You get structured, searchable logs with timestamp and file/line information, with essentially zero impact on your application's timing.

probe-rs is the debugging and flashing tool that talks to your Raspberry Pi Debug Probe over USB. A single cargo run compiles your code, flashes it to the Pico, resets the chip, and starts streaming RTT logs to your terminal. The development loop is as fast as any other language — faster than most, because cargo's incremental compilation only recompiles what changed.

The Pico ships with MicroPython support and it is the most accessible entry point for beginners. Why not use it? Three reasons. First, performance: MicroPython runs an interpreter loop. Every Python statement is interpreted at runtime. On a 150MHz ARM Cortex-M33, interpreted Python executes at roughly the speed of a 5MHz processor. For the bit-banging protocol work in Chapter 8, you need microsecond-level timing precision that interpreted code cannot reliably provide. Second, size: the MicroPython runtime itself occupies approximately 200KB of flash — more than a third of the Pico's total flash, before you write a line of application code. Third, safety: MicroPython gives you dynamic typing and no compile-time error checking. The errors you find in C at runtime you also find in MicroPython at runtime. Rust finds them at compile time.

Rust has a reputation for being difficult to learn. This reputation is partially deserved. The borrow checker — which we cover in depth in the next chapter — will reject code that feels correct to a programmer coming from C or Python. The error messages are excellent (better than any other compiled language's), but understanding them requires understanding the ownership model, and understanding the ownership model requires time.

Here is the honest assessment: the learning curve is steeper than Python and roughly comparable to learning C properly (not just writing C that mostly works). The difference is that what you learn in Rust transfers to every program you write in it. There is no runtime debugging of memory corruption bugs because they cannot exist. There is no mystery crash that only happens on production hardware. The difficulty is front-loaded — paid at compile time, in the form of understanding the compiler's reasoning — and the benefit is a fundamentally different quality of software at the end.

For an engineer of your seniority, with your background in systems that have to work in harsh environments — remote oil fields, cellular towers in rural Uganda, data centres with inconsistent power — the Rust mental model should feel right. The discipline it demands is the discipline you already apply to infrastructure work. The checklist methodology is the same. Rust is just the compiler applying your checklist automatically on every build.