Overview Aotearoa Research Science
In this branch: Foundations Python Rust AI & IT Ecosystem References Readme
Research · Computer Science

Rust: Ownership, Memory Safety & Systems Programming

Rust solves the fundamental tension in systems programming — achieving C-level performance without undefined behaviour — through a novel ownership type system that proves memory safety at compile time.

Watch — a short tour of this page, narrated in my own AI-cloned voice.

1. Origins & Motivation

Rust began as a personal project of Graydon Hoare at Mozilla Research in 2006. Mozilla sponsored the project from 2009, and the first stable release (Rust 1.0) shipped in May 2015. Matsakis and Klock’s 2014 paper[27] is the canonical academic description of the language’s goals.

The motivation was direct: C and C++ remain dominant in systems programming, but their manual memory management leads to a category of vulnerabilities — buffer overflows, use-after-free, dangling pointers, data races — that are widely reported to account for roughly two-thirds of critical security bugs in large codebases (Microsoft Security Response Center’s 2019 analysis put the share at around 70% of assigned CVEs; Google’s Project Zero and Chromium team have reported comparable proportions). Rust eliminates this entire class of errors without a garbage collector, by encoding the rules of safe memory access in the type system itself.

“Rust is a systems programming language focused on three goals: safety, speed, and concurrency.”
— Matsakis & Klock, The Rust Language, ACM SIGAda Ada Letters, 2014[27]

2. Ownership & Borrowing

Rust’s central innovation is its ownership system: every value has exactly one owner at any given time, and the value is dropped (freed) when the owner goes out of scope. This is enforced at compile time with no runtime overhead.

2.1 The Three Rules of Ownership

  1. Every value in Rust has a variable that is its owner.
  2. There can only be one owner at a time.
  3. When the owner goes out of scope, the value will be dropped.
fn main() {
    let s1 = String::from("hello"); // s1 owns the String
    let s2 = s1;                    // ownership MOVED to s2; s1 invalid
    // println!("{}", s1);          // ← compile error: value moved
    println!("{}", s2);             // fine
} // s2 dropped here; heap memory freed automatically

2.2 Borrowing

Rather than transferring ownership, Rust allows references — borrows. The borrow checker enforces one invariant: you may have either any number of shared (&T) references, or exactly one exclusive (&mut T) reference, but never both simultaneously. This is equivalent to a readers-writer lock enforced at compile time — it is why Rust programs have no data races by construction.

fn length(s: &String) -> usize {
    s.len() // borrow; s is not moved
}

fn main() {
    let s = String::from("hello");
    let len = length(&s); // pass a reference
    println!("{} has {} characters", s, len); // s still valid
}

// Mutable borrow — exclusive access
fn append(s: &mut String) {
    s.push_str(", world");
}

fn main() {
    let mut s = String::from("hello");
    append(&mut s);
    println!("{}", s); // "hello, world"
}

3. Lifetimes

Lifetimes are Rust’s mechanism for ensuring that references never outlive the data they point to — preventing dangling pointers. Most lifetimes are inferred by the compiler; explicit lifetime annotations are only needed when the compiler cannot infer them, typically in function signatures returning references:

// 'a is a lifetime parameter: the returned reference lives
// at least as long as the shorter of x and y
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

Lifetimes allow Rust to implement zero-copy parsing, arena allocation, and self-referential data structures safely, patterns that require manual auditing in C and are simply impossible in safe Python or Java.

4. Traits & Generics

Rust’s traits are its mechanism for polymorphism — analogous to Haskell’s type classes and Java’s interfaces, but with no virtual dispatch overhead when used with generics (monomorphisation). A trait defines a set of methods a type must implement:

trait Summary {
    fn summarise(&self) -> String;
    fn preview(&self) -> String {
        format!("{}...", &self.summarise()[..50])
    }
}

struct Article { title: String, body: String }

impl Summary for Article {
    fn summarise(&self) -> String {
        format!("{}: {}", self.title, self.body)
    }
}

// Generic function — monomorphised at compile time (zero overhead)
fn notify(item: &impl Summary) {
    println!("Breaking: {}", item.summarise());
}

4.1 Key Standard Library Traits

TraitPurpose
Clone / CopyExplicit / implicit bitwise copy semantics
Send / SyncMarker traits: safe to transfer / share across threads
IteratorLazy sequence protocol; enables map, filter, fold chains compiled to tight loops
From / IntoInfallible type conversions
ErrorStandard error trait; enables ? operator ergonomics
Display / DebugHuman / developer string formatting

5. Zero-Cost Abstractions

Bjarne Stroustrup coined the term “zero-overhead principle” for C++: what you don’t use, you don’t pay for, and what you do use, you couldn’t hand-code better. Rust inherits and strengthens this principle. Iterator chains, for example, are compiled by LLVM to the same machine code as hand-written loops:

// High-level iterator chain
let sum: i64 = (0..1_000_000_i64)
    .filter(|x| x % 2 == 0)
    .map(|x| x * x)
    .sum();

// LLVM compiles this to a single tight loop with SIMD vectorisation —
// equivalent to the best hand-written C

5.1 Enums & Pattern Matching

Rust’s enum types are algebraic data types (sum types) — each variant can carry different data. The Option<T> and Result<T, E> enums replace null pointers and exceptions respectively, making error paths explicit and exhaustively checked at compile time:

use std::num::ParseIntError;

fn parse_double(s: &str) -> Result<i32, ParseIntError> {
    let n: i32 = s.trim().parse()?; // ? propagates errors
    Ok(n * 2)
}

match parse_double("21") {
    Ok(v)  => println!("Got {}", v),   // 42
    Err(e) => eprintln!("Error: {}", e),
}

6. Async Rust

Rust’s async/await (stabilised in Rust 1.39, November 2019) enables zero-cost asynchronous programming. Unlike Python’s asyncio (which is single-threaded), Rust async futures are poll-based state machines compiled at zero overhead, and they can execute on multi-threaded runtimes like Tokio:

use tokio::net::TcpListener;
use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let listener = TcpListener::bind("127.0.0.1:8080").await?;
    loop {
        let (mut socket, _) = listener.accept().await?;
        tokio::spawn(async move {
            let mut buf = [0u8; 1024];
            let n = socket.read(&mut buf).await.unwrap();
            socket.write_all(&buf[..n]).await.unwrap();
        });
    }
}

Tokio (the dominant async runtime) powers Cloudflare Workers, the AWS Lambda runtime, and numerous high-performance network services. The axum and actix-web frameworks sit atop Tokio, offering ergonomic HTTP server APIs with performance benchmarks competitive with Go and Node.js.

7. Unsafe Rust & FFI

The unsafe keyword creates a block in which the programmer assumes responsibility for a set of invariants the compiler cannot verify: raw pointer dereferencing, calling unsafe functions (including C FFI), implementing unsafe traits. The key insight is that unsafe code is localised — a small audited surface wraps unsafe operations, and the rest of the codebase remains safe.

// FFI to a C function
extern "C" {
    fn abs(x: i32) -> i32;
}

fn safe_abs(x: i32) -> i32 {
    unsafe { abs(x) }
    // Unsafe is contained; callers see a safe API
}

PyO3 is the canonical Rust/Python bridge: it allows writing Python extension modules in Rust with zero-cost type conversions and GIL-aware designs. The uv package manager, ruff linter, and Polars DataFrame library are all written in Rust with PyO3 bindings — demonstrating the complementary relationship between the two languages.

8. Ecosystem & Adoption

DomainNotable Rust ProjectReplaces / Complements
Web browserFirefox (Servo, Stylo, WebRender)C++ components
OS kernelLinux 6.1+ (Rust subsystem)C driver code
Cloud runtimeAWS Firecracker (microVM)QEMU/KVM
WebAssemblywasm-bindgen, wasmtimeC/C++ WASM toolchains
Toolingruff, uv, ripgrep, fdPython/Go equivalents
NetworkingCloudflare Pingora (proxy)NGINX (C)
Data processingPolars DataFramePandas (via PyO3 API)
CryptographyrustlsOpenSSL

Rust has consistently ranked as the most admired (formerly “most loved”) programming language in the Stack Overflow Developer Survey, retaining that position for multiple consecutive years. Its inclusion in the Linux kernel — initial Rust infrastructure was merged into Linux 6.1, released in December 2022 — is a landmark moment, marking the first time an additional language has joined C for mainline kernel development in the kernel’s roughly three-decade history.

9. Formal Verification: RustBelt

Jung et al.’s RustBelt project[28] provides the first formal proof of Rust’s safety guarantees. Using the Iris separation logic framework on top of the Coq proof assistant, RustBelt proves that Rust’s type system correctly enforces memory safety and thread safety — not just for safe Rust, but for code that uses unsafe in the standard library (e.g., Mutex<T>, Arc<T>).