Beyond Memory Safety: What Makes Rust Different – Lessons from Autonomous Robotics

Over the last couple of years, I have been working in the field of autonomous mobile robotics, which is where many of the examples in this article originate. My goal here is to explore what makes Rust special beyond its well-known memory safety guarantees, specifically, how the language prepares developers to write software that is more correct from the outset, where common mistakes become difficult to make, and where the resulting code is inherently more failure-proof.

Beyond Memory Safety

In my conversations with developers about Rust, a consistent pattern emerges: Those who have not invested significant time in the language tend to dismiss it, often after a brief, unsuccessful first attempt. However, in my experience, developers who persist through the initial learning curve and apply Rust to real projects tend to develop a strong appreciation for it. I still remember when we started a large new project two and a half years ago, bringing together people from different language backgrounds into an all-Rust codebase. 

One colleague, coming from C++, spent the first two weeks complaining to me every single day. Then, after about three to four weeks, something shifted. He started genuinely enjoying the language and now says he never wants to go back.

This example may help explain why Rust consistently ranks as the most loved language in Stack Overflow surveys. While memory safety is undoubtedly valuable and I highly benefit from it in my projects, there is more to the story. Rust makes it substantially easier to write software that is correct from the start, where developer mistakes are harder to introduce, and where the resulting code demonstrates greater resilience to failures.

A Simple Core

At its core, Rust is a relatively simple language. The widespread perception of Rust as extremely difficult with a steep learning curve contains some truth, but examining the fundamentals reveals that the language centers on data types and the functions that operate on them. Many concepts from other languages that add complexity are simply absent: no garbage collection, no classes, no inheritance, no traditional object-oriented programming, no null pointers, no function overloading, and no type coercion. This minimalist approach has led some developers to compare Rust’s feel to C or, more recently, to Zig.

Enums: More than Just Integers

Rust enums differ fundamentally from their counterparts in other languages because enum variants can store data. Each variant of an enum can hold specific data that differs from other variants, or it can hold no data at all. This concept resembles tagged unions in TypeScript, but in Rust, it exists as a unified, first-class language feature.

Pattern Matching and Exhaustiveness

To access the data within an enum, developers must match the enum with a construct similar to switch statements in other languages. The match expression allows checking which variant a value actually holds and executing the corresponding logic. Critically, when inside a specific match arm, the compiler grants access to the associated data only for that variant. Matches must be exhaustive, meaning every variant must be handled either explicitly or through catch-all patterns, preventing developers from accidentally forgetting to handle a case.

Modeling Optional Data

Optional data appears everywhere in software systems. Many languages model this concept using null pointers, nil values, or specialized standard library types. In Rust, optional data is modeled using the Option type, a simple enum defined in the standard library that any developer could implement in under a minute. The Option enum has two variants: None, which holds no data, and Some(T), which wraps a generic value.

// Optional data is protected from accidental access.
// One can only access data in Some if it is actually present.

// Option type as it is implemented in the standard library.
enum Option {
  None,
  Some(T)  
}

// Matching on an option is required to access the data.
match &robot.active_job {
  None => return,
  Some(job) => {
    publish_job_update(job);
  },
}

Due to the rules governing data access in enums, optional data is protected from accidental access. In my robotics work, for example, a robot may have an active job or be idle. Modeling this behavior with an Option requires matching on the value before accessing the job data, ensuring that code only operates on jobs that actually exist.

State Machines with Enums

State management is ubiquitous in software development. One intuitive approach in Rust models state using enums, where each variant represents a state and wraps state-specific data. For a robot, states might include Uninitialized (awareness of the robot’s existence), Initialized (with a known position), and ExecutingJob (with both position and job information).

// Each variant models a unique state with its data.
// Constructing a new state requires the data to be present.
enum RobotState {
   Uninitialized,
   Initialized {
       position: Position2d,
   },
   ExecutingJob {
       position: Position2d,
       job: Job,
   }
}

This approach provides two-way protection: The data is protected from accidental access while in the wrong state, and transitioning to a new state requires providing the necessary data, making it impossible to construct invalid states. The compiler enforces these constraints automatically.

Ownership: There Can Only Be One

Ownership represents a core Rust concept that has no direct equivalent in other mainstream languages. The rules are straightforward: Every value in Rust has exactly one owner at any time, no more, no fewer. The compiler enforces this rule through static analysis at compile time.

Lifecycle Management

Rust can precisely track value lifecycles because ownership clearly identifies who owns each value and when ownership goes out of scope. When an owner goes out of scope, the owned value is dropped, memory is freed, and other resources are released.

Ownership Transfer

Ownership can be transferred, or “moved” through assignments or function calls. When data is moved, ownership transfers from the original owner to the new one. The original owner can no longer access the value. This mechanism prevents what I call “double-use” situations, where an entity that should exist uniquely is accidentally used multiple times.

// Ownership can be moved.
let x = y // Ownership is moved from y to x

In robotics systems, a job can only be executed once and by a single robot at a time. Consider a function signature where a job parameter takes a Job by value; in other words, the function takes ownership of the job. When assigning a job to a robot, the ownership moves from the calling code into the function. 

Attempting to assign the same job to two different robots produces a compile-time error because the first assignment moved ownership away from the original variable. This is how ownership transfer elegantly prevents double use at compile time.

impl Robot {
    // Take a job by value and assign it to the robot.
    fn assign_job(&self, job: Job) {...}
}

// Moves the next job out of the queue.
let new_job = jobs_queue.pop_front()?;

// Moves the job into the robot.
robot_1.assign_job(new_job);

// This causes a compilation error since new_job was moved!
robot_2.assign_job(new_job);

error[E0382]: use of moved value: `new_job`

Resource Management Beyond Memory

Value lifecycles can manage more than memory. By hooking into the drop event through the Drop trait, custom behavior can be written for values going out of scope. In robotics, physical spaces like tight corridors may permit only one robot at a time. A ZoneAccess token type can represent permission to enter such a zone. Only one token can exist at a time, because ZoneAccess can be neither copied nor cloned.

impl ZoneRegistry {
    // Access can be requested through a blocking method. Once free,
    // a ZoneAccess token is returned.
    pub fn request_access(
      &self, 
      zone: &ZoneId
    ) -> ZoneAccess {...}
}

// When the token is dropped, the zone is marked again as free.
impl Drop for ZoneAccess {
    fn drop(&mut self) { 
        self.zone_registry.free(&self.id);
    }
}

Implementing Drop for ZoneAccess to automatically free the zone eliminates the need to manually handle every code path where the zone might need to be released, like a robot disconnecting, changing its state, or any other scenario. When the robot owning the ZoneAccess goes out of scope, the token also goes out of scope, and the resource is freed. This pattern prevents resource leakage across all code paths automatically, making it dramatically easier to handle real-world resources beyond just memory.

Borrowing: Safely Referencing Data

If data could only be owned, the language would be severely limited. Borrowing provides a way to safely reference data without taking ownership. The borrowing rules state that at any given time, there can be either a single mutable reference to a value or any number of immutable references, but not both simultaneously.

// Mutable borrow allows mutating the referenced value.
let x = &mut y;

// Immutable borrow just allows looking at it.
let x = &y;

This rule is essential for memory safety because it eliminates data races from multiple code locations accessing the same variable. Mutable borrows allow modifying the underlying data; immutable borrows allow only reading. Importantly, borrowing does not move ownership: The original owner retains ownership while references exist.

Lifetimes: Is This Data Still Safe to Use?

Lifetimes work alongside borrowing to answer whether a borrow remains valid at a particular point in program execution. A reference’s lifetime cannot exceed the lifetime of the value it references; this rule is fundamental for memory safety, because it prevents referencing values after they have been freed.

Variable lifetimes begin at creation and end at destruction. The compiler uses this information for lifetime checking. Most of the time, explicit lifetime annotations are unnecessary because the compiler infers them. Occasionally, explicit annotations are required, using syntax like 'a to denote named lifetimes.

Embedding Protocols into Types

Using ownership, borrowing, and lifetimes together permits something particularly fascinating: embedding runtime protocols into types at compile time. A compelling example comes from Serde, Rust’s primary serialization library.

struct Serializer {...}

impl Serializer {
    // Consume the generic serializer to return a specialized one. 
    pub fn serialize_struct(
        self,
        name: &'static str, 
        len: usize
    ) -> SerializeStruct {...}
    ...
}

The Serializer Pattern

Consider a serializer type that facilitates serializing a single value. A Serializer implements methods for various value types, integers, floats, enums, and structs. The serialize_struct function takes self by value, meaning it consumes the serializer instance. After calling this function, the original serializer cannot be accessed again. The function returns a SerializeStruct, a transformation from a generic serializer to one specialized for struct serialization.

struct SerializeStruct {...}

impl SerializeStruct {
    // Serializing a field takes self by mutable reference. It can be
    // called repeatedly.
    pub fn serialize_field(
        &mut self, 
        key: &'static str, 
        value: &str
    ) {...}

    // Calling end takes ownership of self. Once called the serializer
    // can no longer be used without causing a compile error.
    pub fn end(self) -> Result<(), Error> {...}
}

The SerializeStruct type implements two methods: serialize_field, which takes an immutable reference to self and can be called repeatedly for multiple fields, and end, which finalizes the serialization. The end function carries significant weight; it might write a closing brace in JSON or compute a file header containing the struct’s byte size. In many serialization libraries, documentation warns against calling other serialization functions after the end, with violations potentially causing crashes or runtime errors.

In Rust, this warning is unnecessary because the end function consumes self. The struct serializer’s ownership moves into the end function, where it is dropped and cannot be used again. Attempting to call methods on the serializer after end produces a compile-time error: “borrow of moved value”. This feature eliminates an entire class of developer bugs at compile time, saving substantial error handling that would otherwise be necessary.

Truly Protected Access with Mutex

Another powerful example involves modeling access to shared data through mutexes. Traditional approaches treat the protected data and the mutex as separate entities, relying on developer discipline to lock the mutex before accessing the data. Rust takes a more robust approach.

Ownership-Based Protection

The Mutex::new method takes data by value, meaning that the data moves into the mutex. Ownership transfers and the data can no longer be accessed outside the mutex. When locking succeeds, it returns a MutexGuard with a lifetime bound to the mutex itself; the guard cannot outlive the mutex.

impl Mutex {
    // Data is moved into the mutex. The mutex takes ownership.
    pub const fn new(t: T) -> Mutex {}
}

// Guard type acquired when locking a mutex. Internally it holds a
// reference to the mutex, which binds its lifetime to the mutex.
pub struct MutexGuard<'a, T: ?Sized + 'a> {}

Accessing the protected data requires dereferencing the guard, which returns a reference. This reference’s lifetime is bound to the guard’s lifetime, which is bound to the mutex’s lifetime. The MutexGuard unlocks the mutex when dropped.

// Data can only be accessed through the guard and only references can be 
// obtained!
let data: &State = *guard;

// The mutex is unlocked once the guard is dropped.
// Dropping also happens automatically whenever the value goes out of 
// scope.
drop(guard);

Combining these properties yields a powerful guarantee: References to protected data cannot exist after the guard is dropped, and because dropping the guard unlocks the mutex, it becomes impossible to hold or use a reference to protected data without holding the lock. 

In my experience with heavily multithreaded code, I have seen numerous cases where developers accidentally held references, passed them around, forgot about them, and then unlocked the mutex, creating subtle concurrency bugs. Rust’s approach eliminates this entire category of errors.

Generics: Powerful Stand-Ins

Generics in Rust are stand-ins, definitions that can be reused with different concrete types. The Option type and collections like Vec demonstrate this pattern, implementing logic once for use with any type. Generics are replaced at compile time through monomorphization, generating specific code for each type specialization. This code eliminates runtime overhead, making generic code as fast as code written for concrete types.

Generics can be bound by traits (defining required behavior) and lifetimes, permitting sophisticated type-level programming.

State Machine with Generics and Typestate

While enums provide an intuitive way to model state, an alternative pattern proves more helpful in certain situations, such as with the typestate pattern, which encodes state information into the type system at compile time.

Encoding States as Types

Consider three types representing robot states: Uninit (an empty zero-size marker type), Init (containing position data), and ExecutingJob (containing position and job data). These types mirror the enum variants from earlier but now exist as separate types.

A Robot type generic over state S can embed state-specific data while maintaining common data like the robot’s name. Implementation blocks can target either the generic robot (for state-independent functionality like accessing the name) or specific type specializations like Robot.

struct Uninit;
struct Init {...};
struct ExecutingJob {...};

// The robot is generic over its state.
struct Robot {
    state: S,
    ...
}

// Methods implemented for all states.
impl Robot {
    pub fn name(&self) -> &str {...}
}

// Methods can also be implemented for specific specializations of the
// state.
impl Robot {
    pub fn init(self, position: Position2d) 
        -> Robot {...}
}

impl Robot {
    pub fn assign_job(self, job: Job) 
        -> Robot {...}

    pub fn position(&self) -> Position2d {...}
}

struct NoPosition;
struct PositionSet;
struct NoMap;
struct MapSet;

// The builder is generic over the position and map status.
struct RobotSimulationBuilder
 {...}

// At first, no position and map is set. Both can be set through methods.
impl RobotSimulationBuilder {
    pub fn set_position(self, position: Position2d) 
        -> RobotSimulationBuilder {...}

    pub fn set_map(self, map: Map) 
        -> RobotSimulationBuilder {...}
}

// The specialization for PositionSet and NoMapSet only allows setting
// a map, a position can no longer be set.
impl RobotSimulationBuilder {
    pub fn set_map(self, map: Map) 
        -> RobotSimulationBuilder {...}
}

...

// Once both position and map are set, a finalizer becomes available.
impl RobotSimulationBuilder {
    pub fn build(self) -> RobotSimulation {...}
}