Memory safety vulnerabilities account for approximately 70% of all CVEs at Microsoft and a similar proportion in Google's Android and Chrome projects. The root cause is manual memory management in C and C++: use-after-free, double-free, buffer overflows, and data races. Garbage-collected languages eliminate these bugs but introduce runtime overhead, unpredictable pause times, and higher baseline memory consumption. Rust takes a third path. Its ownership system enforces memory safety at compile time with zero runtime cost.
The Problem Space
C and C++ provide direct memory control. That control comes with a class of bugs that has persisted for over four decades.
// Use-after-free: the pointer is dangling
char *ptr = malloc(10);
free(ptr);
printf("%s", ptr); // undefined behavior
// Double free: corrupts heap allocator metadata
free(ptr);
free(ptr); // heap corruption
// Buffer overflow: stack smashing, potential code execution
char buf[10];
strcpy(buf, "this string exceeds the buffer capacity by a wide margin");These are not obscure edge cases. They are the most commonly exploited vulnerability classes in production software. The MITRE CWE Top 25 (2024) lists out-of-bounds write, use-after-free, and out-of-bounds read in its top ten.
Garbage-collected languages (Java, Go, Python, C#) eliminate this category entirely. The tradeoff is quantifiable:
+---------------------+---------+--------+--------+
| Metric | C/C++ | Go | Rust |
+---------------------+---------+--------+--------+
| GC pause (p99) | N/A | 1-10ms | N/A |
| Memory overhead | ~1x | ~2-4x | ~1x |
| Binary size (hello) | ~16 KB | ~1.8MB | ~300KB |
| Startup time | <1ms | ~5ms | <1ms |
| Data race possible | Yes | Yes* | No** |
+---------------------+---------+--------+--------+
* Go's race detector is sampling-based, not exhaustive
** In safe Rust. Unsafe blocks can introduce data races.
For systems software (kernels, databases, network proxies, embedded firmware), the GC tradeoff is often unacceptable. Rust provides C-level performance with compile-time safety guarantees.
Ownership: The Core Mechanism
Rust's ownership model rests on three rules enforced at compile time:
- Every value has exactly one owner.
- When the owner goes out of scope, the value is dropped (destructor runs, memory freed).
- At any point, a value can have either one mutable reference or any number of immutable references, never both simultaneously.
fn main() {
// s1 owns the heap-allocated string
let s1 = String::from("hello");
// Ownership moves from s1 to s2.
// s1 is invalidated. No copy of heap data occurs.
let s2 = s1;
// This would fail to compile:
// println!("{}", s1); // error[E0382]: borrow of moved value: `s1`
// Explicit deep copy requires .clone()
let s3 = s2.clone();
// Both s2 and s3 are valid, each owns independent heap data
println!("{} {}", s2, s3);
}
// s2 and s3 are dropped here. Each frees its own heap allocation.The memory layout during a move:
Before: let s1 = String::from("hello");
Stack Heap
+------------------+ +---+---+---+---+---+
| s1 | | h | e | l | l | o |
| ptr: 0xA000 ---|-------------->+---+---+---+---+---+
| len: 5 | addr: 0xA000
| cap: 5 |
+------------------+
After: let s2 = s1;
Stack Heap
+------------------+ +---+---+---+---+---+
| s1 [INVALIDATED] | | h | e | l | l | o |
| (cannot use) | +------>+---+---+---+---+---+
+------------------+ | addr: 0xA000
| s2 | |
| ptr: 0xA000 ---+-------+
| len: 5 |
| cap: 5 |
+------------------+
Only the 24-byte stack metadata (ptr, len, cap) is copied.
The heap data stays in place. s1 is statically invalidated.
No runtime check. No reference count. No GC.
In C++, std::string assignment performs a deep copy by default. std::move transfers ownership but leaves the source in a "valid but unspecified state," meaning use-after-move is not a compile error. Rust makes moves the default, makes copies explicit via .clone(), and makes use-after-move a hard compile error.
Stack vs. Heap: Type-Level Distinction
Rust distinguishes between types that can be trivially copied (stack-only, fixed-size) and types that own heap resources.
Stack Frame Layout Heap
+---------------------------+ +------------------+
| x: i32 = 42 | | |
| y: f64 = 3.14 | | +-----------+ |
| flag: bool = true | | | "hello" | |
| | | | h e l l o | |
| s: String | | +-----------+ |
| ptr ---------------------->-------+ addr: 0xB000 |
| len: 5 | | |
| cap: 5 | | +-----------+ |
| | | | [1,2,3,4] | |
| v: Vec<i32> | | +-----------+ |
| ptr ---------------------->-------+ addr: 0xC000 |
| len: 4 | | |
| cap: 8 | +------------------+
+---------------------------+
Fixed size per frame, Dynamic size,
O(1) alloc/dealloc (sp adjust), alloc/dealloc via
LIFO discipline system allocator
Types implementing Copy (integers, floats, booleans, tuples of Copy types) are duplicated on assignment. This is a bitwise copy of a few bytes on the stack, which is effectively free.
Types implementing Drop (String, Vec, Box, File handles, network sockets) own resources that must be cleaned up. These types cannot implement Copy because duplicating the stack metadata without duplicating the heap data would create aliased ownership, leading to double-free.
// Copy types: assignment duplicates the value
let a: i32 = 42;
let b = a; // bitwise copy, both a and b are valid
println!("{} {}", a, b); // works fine
// Drop types: assignment moves the value
let s1 = String::from("data");
let s2 = s1; // move, s1 is invalidated
// println!("{}", s1); // compile errorThis distinction is encoded in the type system and enforced at compile time. There is no runtime dispatch to determine whether a value should be copied or moved.
Borrowing and the Borrow Checker
Transferring ownership on every function call would be impractical. Borrowing allows functions to access data without taking ownership.
// Immutable borrow: read-only access
fn compute_length(s: &String) -> usize {
s.len()
// s is a reference, not an owner.
// Nothing is dropped when s goes out of scope.
}
// Mutable borrow: read-write access (exclusive)
fn append_exclamation(s: &mut String) {
s.push('!');
}
fn main() {
let mut greeting = String::from("hello");
// Immutable borrow
let len = compute_length(&greeting);
// Mutable borrow
append_exclamation(&mut greeting);
println!("{} (original length: {})", greeting, len);
// Output: hello! (original length: 5)
}The borrow checker enforces the aliasing XOR mutability rule:
ALLOWED configurations:
Case 1: Multiple readers, no writers
+-------+
| &data | ---- reader A
+-------+
| &data | ---- reader B (any number of &T)
+-------+
| &data | ---- reader C
+-------+
Case 2: Single writer, no readers
+-----------+
| &mut data | ---- writer A (exactly one &mut T)
+-----------+
REJECTED at compile time:
Case 3: Reader + writer simultaneously
+-------+
| &data | ---- reader A CONFLICT: compiler rejects
+-------+ this program entirely.
+-----------+ No binary is produced.
| &mut data | ---- writer A
+-----------+
A concrete example of the borrow checker preventing a real bug:
fn main() {
let mut items = vec![1, 2, 3, 4, 5];
// Take an immutable reference to the first element
let first = &items[0];
// Attempt to push a new element.
// This might cause Vec to reallocate its backing array,
// which would invalidate the reference held by `first`.
// items.push(6); // error[E0502]: cannot borrow `items` as
// mutable because it is also borrowed as immutable
// The reference must be used (or go out of scope) before mutation
println!("first element: {}", first);
// Now the immutable borrow is no longer active.
// Mutation is permitted.
items.push(6);
}In C++, this pattern compiles without warnings and causes undefined behavior if the vector reallocates. Iterator invalidation bugs are a well-documented source of crashes and security vulnerabilities in C++ codebases.
Lifetimes
A lifetime is the scope during which a reference is valid. The compiler tracks lifetimes to ensure no reference outlives the data it points to.
// Explicit lifetime annotation: the returned reference
// lives at least as long as both input references.
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
if x.len() > y.len() { x } else { y }
}The lifetime parameter 'a is not a runtime construct. It is a constraint the compiler uses during static analysis. No code is generated for lifetimes.
Lifetime analysis for longest():
Caller scope:
+--------------------------------------------------+
| let a = String::from("long string"); |
| +--------------------------------------------+ |
| | let b = String::from("hi"); | |
| | | |
| | let result = longest(&a, &b); | |
| | // result: &str with lifetime 'a | |
| | // 'a = intersection of a's and b's scope | |
| | // = b's scope (the shorter one) | |
| | | |
| | println!("{}", result); // OK: b alive | |
| +--------------------------------------------+ |
| // b dropped here |
| |
| // println!("{}", result); |
| // ERROR if result were used here: |
| // b is no longer valid, result might |
| // reference b's data |
+--------------------------------------------------+
Lifetime elision rules handle most common patterns automatically:
// Written by programmer:
fn first_word(s: &str) -> &str {
let bytes = s.as_bytes();
for (i, &byte) in bytes.iter().enumerate() {
if byte == b' ' {
return &s[..i];
}
}
s
}
// Compiler applies elision rule:
// "If there is exactly one input lifetime, assign it to all output lifetimes."
// Equivalent to:
fn first_word<'a>(s: &'a str) -> &'a str { /* ... */ }The three elision rules cover approximately 90% of practical cases:
- Each reference parameter gets its own lifetime parameter.
- If there is exactly one input lifetime, it is assigned to all output lifetimes.
- If one of the parameters is
&selfor&mut self, the lifetime ofselfis assigned to all output lifetimes.
When elision is insufficient, the compiler emits a specific error requesting explicit annotation. The annotation does not change program behavior. It provides the compiler with enough information to verify safety.
Struct Lifetimes and Complex Borrowing
Lifetimes in struct definitions ensure that the struct cannot outlive the data it references.
// This struct holds a reference, so it needs a lifetime parameter.
// The struct cannot outlive the string slice it borrows.
struct Excerpt<'a> {
text: &'a str,
line_number: usize,
}
impl<'a> Excerpt<'a> {
// Elision rule 3 applies: &self lifetime assigned to output
fn first_ten_chars(&self) -> &str {
if self.text.len() >= 10 {
&self.text[..10]
} else {
self.text
}
}
}
fn main() {
let novel = String::from("Call me Ishmael. Some years ago...");
// excerpt borrows from novel
let excerpt = Excerpt {
text: &novel[..16],
line_number: 1,
};
println!("Line {}: {}", excerpt.line_number, excerpt.text);
// Output: Line 1: Call me Ishmael.
// If novel were dropped here, excerpt would be a dangling reference.
// The compiler prevents this.
}Fearless Concurrency
The ownership model extends to thread safety. Rust's type system enforces two key traits:
Send: a type can be transferred to another thread.Sync: a type can be shared (via reference) between threads.
Most types implement both. Types like Rc<T> (non-atomic reference counting) are neither Send nor Sync, so the compiler rejects any attempt to share them across threads.
use std::thread;
use std::sync::{Arc, Mutex};
fn main() {
// Arc: atomic reference counting (thread-safe shared ownership)
// Mutex: mutual exclusion (thread-safe interior mutability)
let counter = Arc::new(Mutex::new(0u64));
let mut handles = vec![];
for _ in 0..10 {
// Clone the Arc (increments atomic refcount, not the data)
let counter_clone = Arc::clone(&counter);
let handle = thread::spawn(move || {
// .lock() returns a MutexGuard.
// The guard implements DerefMut, providing &mut access.
// When the guard is dropped, the lock is released.
let mut val = counter_clone.lock().unwrap();
*val += 1;
// MutexGuard dropped here, lock released automatically
});
handles.push(handle);
}
for handle in handles {
handle.join().unwrap();
}
println!("Final count: {}", *counter.lock().unwrap());
// Output: Final count: 10 (guaranteed, no data race possible)
}The ownership flow for concurrent access:
Main Thread Thread 1 Thread 2
========== ======== ========
Arc::new(Mutex(0))
refcount: 1
|
Arc::clone()
refcount: 2
|----------move---> Arc (refcount: 2)
| |
Arc::clone() |
refcount: 3 |
| lock()
| MutexGuard(&mut 0)
| *val += 1
| drop(guard) <-- lock released
|
+---------move---> Arc (refcount: 3)
|
lock()
MutexGuard(&mut 1)
*val += 1
drop(guard) <-- lock released
join() thread 1
join() thread 2
refcount: 1
lock()
read: 2
drop all --> refcount 0 --> Mutex dropped --> value dropped
A critical point: attempting to access the data inside a Mutex<T> without calling .lock() does not compile. The type system guarantees that the lock protocol is followed. This is a structural guarantee, not a convention.
Contrast with Go, where sharing mutable state across goroutines requires discipline rather than compiler enforcement:
// Go: this compiles and runs, but has a data race
var counter int
var wg sync.WaitGroup
for i := 0; i < 10; i++ {
wg.Add(1)
go func() {
defer wg.Done()
counter++ // data race: no synchronization
}()
}Go's race detector (-race flag) catches this at runtime via sampling. It is not exhaustive and is typically disabled in production builds due to performance overhead (2-10x slowdown). Rust prevents the equivalent code from compiling at all.
Zero-Cost Abstractions
Rust's iterator combinators compile to the same machine code as hand-written loops.
// Functional style: filter, map, fold
fn sum_of_even_squares_v1(limit: i64) -> i64 {
(1..=limit)
.filter(|x| x % 2 == 0) // keep even numbers
.map(|x| x * x) // square each
.sum() // accumulate
}
// Imperative style: explicit loop
fn sum_of_even_squares_v2(limit: i64) -> i64 {
let mut sum: i64 = 0;
let mut i: i64 = 1;
while i <= limit {
if i % 2 == 0 {
sum += i * i;
}
i += 1;
}
sum
}
// Both functions produce identical assembly output
// when compiled with `rustc -O` (release mode).
// No heap allocation. No intermediate Vec. No closure overhead.
// The iterator adapter chain is fused by LLVM into a single loop.This is achieved through monomorphization: the compiler generates specialized code for each concrete type. There is no type erasure, no boxing, no vtable lookup.
Monomorphization of Vec<T>::push:
Source code: Compiled output:
+-----------------+ +-------------------------+
| Vec<T>::push | ---> | Vec_i32_push (inlined) |
| | | Vec_f64_push (inlined) |
| | | Vec_String_push |
+-----------------+ +-------------------------+
Each instantiation is optimized independently.
The compiler can inline, vectorize (SIMD), and
eliminate bounds checks where it can prove safety.
Benchmark comparison (Fibonacci sequence, n=40, compiled with equivalent optimization flags):
+-----------+------------+------------+------------+
| Language | Time (ms) | Memory (KB)| Binary (KB)|
+-----------+------------+------------+------------+
| C (gcc) | 320 | 120 | 16 |
| Rust | 325 | 140 | 300 |
| Go | 540 | 3200 | 1800 |
| Java | 380 | 28000 | N/A |
+-----------+------------+------------+------------+
Measured on x86_64, -O2 / --release, single-threaded.
Rust and C produce comparable assembly for numeric computation.
Go overhead comes from goroutine stack management and GC metadata.
For I/O-bound workloads (HTTP servers, database drivers), the gap between Rust and Go narrows. For CPU-bound or memory-sensitive workloads (parsers, compression, cryptography), Rust matches or exceeds C performance while maintaining safety.
Trait Objects and Dynamic Dispatch
Rust supports two forms of polymorphism: generics (static dispatch) and trait objects (dynamic dispatch).
use std::fmt::Display;
// Static dispatch: monomorphized at compile time.
// The compiler generates a separate function body for each concrete type.
// Zero runtime overhead. Enables inlining.
fn print_static<T: Display>(item: &T) {
println!("{}", item);
}
// Dynamic dispatch: resolved at runtime via vtable.
// One function body. Pointer indirection on each method call.
// Smaller binary. Cannot inline across the dispatch boundary.
fn print_dynamic(item: &dyn Display) {
println!("{}", item);
}The vtable layout for a trait object:
&dyn Display (fat pointer, 2 * usize)
+-------------+-------------+
| data_ptr | vtable_ptr |
+------+------+------+------+
| |
v v
+------+------+ +-------------------+
| actual data | | drop_fn_ptr |
| (e.g., i32) | | size |
+-------------+ | align |
| fmt_fn_ptr | <-- Display::fmt
+-------------------+
Cost per dynamic call: one pointer dereference
to load the function pointer, then an indirect call.
Typically 1-3 ns overhead compared to static dispatch.
Practical usage guidelines:
// Use generics when:
// - Performance is critical (hot loops)
// - The set of types is known at compile time
// - You want the compiler to optimize each specialization
fn process_all<T: Handler>(handlers: &[T]) {
for h in handlers {
h.handle(); // static dispatch, can be inlined
}
}
// Use trait objects when:
// - You need heterogeneous collections
// - You want to reduce binary size / compile time
// - You are building plugin-style architectures
fn process_all_dynamic(handlers: &[Box<dyn Handler>]) {
for h in handlers {
h.handle(); // dynamic dispatch via vtable
}
}Unsafe Rust
The unsafe keyword unlocks five specific capabilities:
- Dereferencing raw pointers (
*const T,*mut T) - Calling functions marked
unsafe - Accessing or modifying mutable static variables
- Implementing traits marked
unsafe - Accessing fields of
uniontypes
All other safety guarantees (ownership, borrowing, type checking, bounds checking) remain in effect inside unsafe blocks.
// Example: safe wrapper around an unsafe operation
pub fn split_at_mut(slice: &mut [i32], mid: usize) -> (&mut [i32], &mut [i32]) {
let len = slice.len();
assert!(mid <= len);
let ptr = slice.as_mut_ptr();
// The borrow checker cannot verify that two mutable slices
// from the same array are non-overlapping. The programmer
// must provide this guarantee.
unsafe {
(
std::slice::from_raw_parts_mut(ptr, mid),
std::slice::from_raw_parts_mut(ptr.add(mid), len - mid),
)
}
}
fn main() {
let mut data = vec![1, 2, 3, 4, 5, 6];
let (left, right) = split_at_mut(&mut data, 3);
// left: [1, 2, 3], right: [4, 5, 6]
// Both are valid, non-overlapping mutable slices.
left[0] = 10;
right[0] = 40;
println!("{:?}", data); // [10, 2, 3, 40, 5, 6]
}The standard library uses unsafe internally for performance-critical data structures (Vec, HashMap, String, Arc). The unsafe blocks are encapsulated behind safe public APIs. This pattern, called "safe abstraction over unsafe code," is the idiomatic approach.
In production Rust codebases, unsafe code typically accounts for less than 1% of total lines. Code audits can focus on these sections, as they are the only locations where memory safety bugs can originate.
FFI: Foreign Function Interface
Rust provides zero-overhead interoperability with C through extern "C" declarations.
use std::ffi::{CStr, CString};
use std::os::raw::c_char;
// Declaring external C functions
extern "C" {
fn strlen(s: *const c_char) -> usize;
fn puts(s: *const c_char) -> i32;
}
// Safe wrapper around C's strlen
fn safe_strlen(s: &str) -> usize {
// CString adds a null terminator, as C expects
let c_str = CString::new(s).expect("string contains null byte");
unsafe { strlen(c_str.as_ptr()) }
}
// Exposing a Rust function to C
#[no_mangle]
pub extern "C" fn rust_hash(data: *const u8, len: usize) -> u64 {
// Validate inputs, then perform the operation
if data.is_null() || len == 0 {
return 0;
}
let slice = unsafe { std::slice::from_raw_parts(data, len) };
// Use Rust's standard hashing
use std::hash::{Hash, Hasher};
use std::collections::hash_map::DefaultHasher;
let mut hasher = DefaultHasher::new();
slice.hash(&mut hasher);
hasher.finish()
}FFI enables incremental adoption. Existing C/C++ systems can call into Rust modules without rewriting the entire codebase. This is the strategy used by several large-scale projects.
Incremental Rust Adoption Pattern:
+---------------------------------------------------+
| Existing C/C++ Application |
| |
| +-------------+ +-------------+ +----------+ |
| | Module A | | Module B | | Module C | |
| | (C, legacy) | | (C, legacy) | | (C, old) | |
| +------+------+ +------+------+ +----+-----+ |
| | | | |
| v v v |
| +------+------+ +-----+-------+ +----+-----+ |
| | Module A | | Module B | | Module C | |
| | (C, legacy) | | (Rust, new) | | (C, old) | |
| +-------------+ +--extern "C"-+ +----------+ |
| |
+---------------------------------------------------+
Modules are replaced one at a time.
The C ABI boundary is the integration point.
No "big bang" rewrite required.
Pin and Async: Self-Referential Types
Async functions in Rust compile to state machines that implement the Future trait. These state machines may contain references to their own fields across .await points, creating self-referential structures.
async fn example() -> String {
let data = fetch_data().await; // state 1
let processed = transform(&data).await; // state 2: holds &data
processed
}
// The compiler generates approximately:
// enum ExampleFuture {
// State1 { /* ... */ },
// State2 { data: Data, ref_to_data: &Data }, // self-referential
// Complete,
// }Moving a self-referential struct in memory invalidates internal pointers:
Self-referential struct at address 0x1000:
+------------------+ addr: 0x1000
| data: [bytes] | <---+
+------------------+ |
| ptr: 0x1000 | ----+ (points to own data field)
+------------------+
After move to address 0x2000:
+------------------+ addr: 0x2000
| data: [bytes] |
+------------------+
| ptr: 0x1000 | ----> DANGLING (old address)
+------------------+
Pin<T> prevents this move from occurring.
Pin<Box<dyn Future>> guarantees that once a future has been polled, it will not be moved in memory. The async runtimes (tokio, async-std) handle pinning automatically in most cases. Manual pinning is only necessary when implementing Future directly or building low-level async primitives.
use std::pin::Pin;
use std::future::Future;
use tokio;
// Returning a pinned, boxed future (heap-allocated, unmovable)
fn make_future(n: u64) -> Pin<Box<dyn Future<Output = u64> + Send>> {
Box::pin(async move {
tokio::time::sleep(tokio::time::Duration::from_millis(n)).await;
n * 2
})
}
#[tokio::main]
async fn main() {
let result = make_future(100).await;
println!("Result: {}", result); // Output: Result: 200
}Real-World Deployments
AWS Firecracker
Firecracker is the virtual machine monitor (VMM) that powers AWS Lambda and AWS Fargate. Written in approximately 50,000 lines of Rust, it provides the security boundary between customer workloads. The choice of Rust was driven by the requirement that the VMM itself must not have memory safety vulnerabilities, as any such bug would compromise multi-tenant isolation. The unsafe surface area in Firecracker is minimal and concentrated in device emulation code that interfaces with KVM.
Cloudflare Pingora
Cloudflare replaced their Nginx-based proxy infrastructure with Pingora, a Rust-based HTTP proxy framework. Published results:
+--------------------+--------+---------+
| Metric | Nginx | Pingora |
+--------------------+--------+---------+
| CPU usage | 1x | 0.5x |
| Memory usage | 1x | 0.67x |
| Connection reuse | low | high |
| Memory safety bugs | common | zero |
+--------------------+--------+---------+
The performance improvement came partly from Rust's ability to support aggressive optimization (connection pooling, zero-copy I/O) without the risk of memory corruption that would make such optimizations dangerous in C.
Android (Google)
Google's Android team published data correlating the percentage of new code written in memory-safe languages with the rate of memory safety vulnerabilities:
Year | % New code in Rust/Java | Memory safety CVEs
------+-------------------------+-------------------
2019 | ~0% Rust | ~223
2020 | ~2% Rust | ~200
2021 | ~10% Rust | ~150
2022 | ~21% Rust | ~85
2023 | ~30% Rust | ~50
The decline in memory safety CVEs tracks the increase in memory-safe code, even though the total codebase size and complexity continued to grow. New Rust components in Android have had zero memory safety vulnerabilities.
Linux Kernel
The Linux kernel accepted Rust as a second implementation language starting with version 6.1 (December 2022). Initial Rust subsystems include a GPIO PL061 driver and an NVMe driver prototype. The significance is not the amount of Rust code currently in the kernel but the policy decision: the most conservative C codebase in widespread use has acknowledged that memory safety at the language level is worth the complexity of supporting a second language.
Error Handling
Rust replaces exceptions with the Result<T, E> and Option<T> types, making error paths explicit in function signatures.
use std::fs;
use std::io;
use std::num::ParseIntError;
#[derive(Debug)]
enum AppError {
Io(io::Error),
Parse(ParseIntError),
}
impl From<io::Error> for AppError {
fn from(e: io::Error) -> Self { AppError::Io(e) }
}
impl From<ParseIntError> for AppError {
fn from(e: ParseIntError) -> Self { AppError::Parse(e) }
}
// The ? operator propagates errors up the call stack.
// If the Result is Err, the function returns early with the error.
// If the Result is Ok, the value is unwrapped and execution continues.
fn read_and_sum(path: &str) -> Result<i64, AppError> {
let contents = fs::read_to_string(path)?; // io::Error -> AppError
let mut sum: i64 = 0;
for line in contents.lines() {
let n: i64 = line.trim().parse()?; // ParseIntError -> AppError
sum += n;
}
Ok(sum)
}
fn main() {
match read_and_sum("numbers.txt") {
Ok(total) => println!("Sum: {}", total),
Err(AppError::Io(e)) => eprintln!("File error: {}", e),
Err(AppError::Parse(e)) => eprintln!("Parse error: {}", e),
}
}The ? operator is zero-cost. It compiles to the same code as an explicit match statement. There is no stack unwinding, no exception table, no hidden control flow.
Pattern Matching and Enums
Rust's enums are algebraic data types. Combined with pattern matching, they provide exhaustive checking at compile time.
// Tagged union: each variant can hold different data
enum Packet {
Ping { seq: u32, timestamp: u64 },
Data { seq: u32, payload: Vec<u8>, checksum: u32 },
Ack { seq: u32 },
Reset,
}
fn handle_packet(packet: Packet) -> Result<(), String> {
// The match must cover all variants.
// Adding a new variant to the enum causes a compile error
// at every match site that does not handle it.
match packet {
Packet::Ping { seq, timestamp } => {
println!("PING seq={} t={}", seq, timestamp);
Ok(())
}
Packet::Data { seq, payload, checksum } => {
// Verify checksum
let computed = crc32(&payload);
if computed != checksum {
return Err(format!("checksum mismatch: seq={}", seq));
}
println!("DATA seq={} len={}", seq, payload.len());
Ok(())
}
Packet::Ack { seq } => {
println!("ACK seq={}", seq);
Ok(())
}
Packet::Reset => {
println!("RESET");
Ok(())
}
}
}This exhaustiveness guarantee eliminates a common class of bugs where a new enum variant is added but not all match sites are updated. In C, a switch statement on an enum with a missing case is a warning at best, silently ignored at worst.
Memory Layout and Optimization
Rust structs have a defined memory layout that the compiler can optimize.
// Default layout: compiler may reorder fields to minimize padding
struct Sensor {
id: u8, // 1 byte
// 7 bytes padding (alignment of f64)
reading: f64, // 8 bytes
active: bool, // 1 byte
// 3 bytes padding (alignment of u32)
timestamp: u32, // 4 bytes
}
// Naive layout: 1 + 7 + 8 + 1 + 3 + 4 = 24 bytes
// repr(C): use C-compatible layout (no reordering)
#[repr(C)]
struct SensorC {
id: u8,
reading: f64,
active: bool,
timestamp: u32,
}
// C layout: 1 + 7 + 8 + 1 + 3 + 4 = 24 bytes (same, but field order preserved)
// Optimized layout: reorder fields to minimize padding
struct SensorOptimized {
reading: f64, // 8 bytes
timestamp: u32, // 4 bytes
id: u8, // 1 byte
active: bool, // 1 byte
// 2 bytes padding
}
// Optimized: 8 + 4 + 1 + 1 + 2 = 16 bytesThe compiler reorders fields in default (repr(Rust)) layout to minimize padding. For FFI or serialization, #[repr(C)] forces C-compatible layout. #[repr(packed)] eliminates padding entirely (at the cost of unaligned access).
Memory layout comparison:
Naive (24 bytes):
+----+-------+--------+------+---+--------+
| id | pad:7 | reading| act |p:3| tstamp |
+----+-------+--------+------+---+--------+
0 1 8 16 17 20 24
Compiler-optimized (16 bytes):
+--------+--------+----+------+-----+
| reading| tstamp | id | act | p:2 |
+--------+--------+----+------+-----+
0 8 12 13 14 16
Enum Size Optimization (Niche Optimization)
The compiler exploits invalid bit patterns to optimize enum sizes.
use std::mem::size_of;
// Option<Box<T>> is the same size as Box<T> (8 bytes on 64-bit)
// because Box<T> can never be null, so the compiler uses
// the null pointer value to represent None.
assert_eq!(size_of::<Box<i32>>(), 8);
assert_eq!(size_of::<Option<Box<i32>>>(), 8); // no overhead
// Same for references:
assert_eq!(size_of::<&i32>(), 8);
assert_eq!(size_of::<Option<&i32>>(), 8); // no overhead
// NonZeroU32 uses the zero value for None:
use std::num::NonZeroU32;
assert_eq!(size_of::<NonZeroU32>(), 4);
assert_eq!(size_of::<Option<NonZeroU32>>(), 4); // no overheadThis niche optimization means Option<T> is truly zero-cost for pointer types. There is no equivalent optimization in C, where nullable pointers require explicit null checks with no type-level distinction between nullable and non-nullable pointers.
Comparison Summary
+---------------------------+--------+--------+--------+
| Property | C/C++ | Go | Rust |
+---------------------------+--------+--------+--------+
| Memory safety (compile) | No | N/A* | Yes |
| Data race freedom | No | No** | Yes*** |
| Zero-cost abstractions | Partial| No | Yes |
| Deterministic destruction | Yes | No | Yes |
| No GC pauses | Yes | No | Yes |
| Null safety | No | No | Yes |
| Pattern match exhaustive | No | No | Yes |
| C ABI compatible | Yes | CGo | Yes |
| Compile speed | Medium | Fast | Slow |
| Learning curve | Medium | Low | High |
+---------------------------+--------+--------+--------+
* Go is GC'd, so memory safety is a runtime property
** Go race detector is runtime, sampling-based
*** In safe Rust only
Rust's compile times are its most significant practical drawback. A clean build of a medium-sized project (50k-100k lines) can take 2-5 minutes. Incremental builds are faster (5-30 seconds) but still slower than Go or C. The cargo check command (type checking without codegen) provides faster feedback during development.
The learning curve is steep. The ownership model, lifetimes, trait system, and async model each represent a significant conceptual investment. The compiler's error messages are detailed and actionable, which reduces but does not eliminate the initial friction.
The payoff is a program that, once it compiles, is free of memory safety bugs, data races, null pointer dereferences, and unhandled error cases. For systems where correctness and performance are both requirements, this tradeoff is increasingly considered worthwhile by organizations building production infrastructure.