⌨️ ~/blog
~/posts/problems_rust_solves
// Title: Key Problems Rust Solves in Modern Programming
// Published: May 11, 2025

Before learning any new programming language, it’s important to understand what problems it solves. When I got interested in Rust, I searched online and asked AI tools like ChatGPT about its benefits. As a newcomer, I wanted to know: what makes Rust different? Here are the key problems Rust was designed to solve:

The Memory Safety Problem

Memory safety is a critical issue in programming, especially in systems languages like C and C++. Bugs related to memory management can lead to crashes, data corruption, and security vulnerabilities.

// In C, memory management errors are easy to make
char* buffer = malloc(1000);
// Use the buffer...
// Oops, we forgot to free! This is a memory leak
if (some_condition) {
    return; // Early return without freeing - memory leak!
}
// This code might never execute
free(buffer);

// Or worse - use-after-free vulnerability
char* ptr = malloc(100);
free(ptr);
strcpy(ptr, "Hello!"); // Dangerous: writing to already freed memory

The Problem: Memory leaks, dangling pointers, and buffer overflows are common pitfalls that can lead to undefined behavior. The Solution: Rust’s ownership model, which enforces strict rules about how memory is accessed and managed. This model ensures that memory is automatically freed when it goes out of scope, preventing leaks and dangling pointers.

Many modern languages like Java, Python, and JavaScript rely on garbage collectors that run in the background, periodically scanning memory to identify and reclaim unused objects. While convenient, garbage collection introduces:

  • Unpredictable pauses in execution
  • Memory overhead for tracking allocations
  • CPU cycles dedicated to garbage collection
  • Complexity in real-time or resource-constrained environments

Rust takes a fundamentally different approach with its ownership system:

  • Each value has exactly one owner
  • When the owner goes out of scope, the value is automatically dropped
  • Memory is freed deterministically and immediately when no longer needed
  • No background processes or runtime overhead
fn main() {
    let s = String::from("Hello, Rust!");
    // s is automatically freed when it goes out of scope
} // No need to manually free memory

The Result: Rust’s compiler checks for memory safety at compile time, reducing the risk of runtime errors and security vulnerabilities. This means you can focus on writing code without constantly worrying about memory management issues.

fn main() {
    // Ownership examples
    let s1 = String::from("Hello");

    // Borrowing example (immutable)
    let len = calculate_length(&s1);
    println!("The length of '{}' is {}.", s1, len); // s1 is still valid here

    // Mutable borrowing
    let mut s2 = String::from("Hello");
    add_world(&mut s2);
    println!("Modified string: {}", s2); // Prints "Hello, world!"

    // Rust prevents multiple mutable references (preventing data races)
    let mut s3 = String::from("Hello");
    let r1 = &mut s3;
    // let r2 = &mut s3; // This would cause a compile error!
    // Cannot have multiple mutable borrows simultaneously
}

fn calculate_length(s: &String) -> usize {
    s.len() // s is borrowed, not owned, so it's not dropped here
}

fn add_world(s: &mut String) {
    s.push_str(", world!");
}

The Concurrency Safety Problem

Concurrent programming has historically been error-prone and difficult to get right. The simplest example of this problem is a bank account transaction:

// In pseudocode (or simplified C-like code)
int account_balance = 100;

// Thread 1: Deposit $50
void deposit() {
    // Read balance
    int temp = account_balance;
    // Modify balance
    temp = temp + 50;
    // Short delay (e.g., context switch to another thread)
    sleep(10);
    // Write back to balance
    account_balance = temp;
}

// Thread 2: Withdraw $70
void withdraw() {
    // Read balance
    int temp = account_balance;
    // Modify balance
    temp = temp - 70;
    // Write back to balance
    account_balance = temp;
}

// If these run concurrently:
// 1. Thread 1 reads balance (100)
// 2. Thread 2 reads balance (100)
// 3. Thread 1 calculates new balance (150)
// 4. Thread 2 calculates new balance (30)
// 5. Thread 1 writes (150)
// 6. Thread 2 writes (30) - overwriting Thread 1's update!
// Final balance: $30 instead of $80!

The Problem: Without proper synchronization, threads can interfere with each other, leading to incorrect results. In real applications, these bugs can be extremely difficult to reproduce and fix.

Rust’s Solution: Rust’s ownership and type systems prevent data races at compile time through the Send and Sync traits. The compiler ensures that data shared between threads is properly synchronized.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    // Thread-safe wrapper around our balance
    let balance = Arc::new(Mutex::new(100));

    // Clone for the deposit thread
    let deposit_balance = Arc::clone(&balance);
    let deposit_thread = thread::spawn(move || {
        // Lock to get exclusive access
        let mut bal = deposit_balance.lock().unwrap();
        *bal += 50;
        // Lock automatically released when bal goes out of scope
    });

    // Clone for the withdraw thread
    let withdraw_balance = Arc::clone(&balance);
    let withdraw_thread = thread::spawn(move || {
        // Lock to get exclusive access - will wait if deposit has the lock
        let mut bal = withdraw_balance.lock().unwrap();
        *bal -= 70;
    });

    // Wait for both threads
    deposit_thread.join().unwrap();
    withdraw_thread.join().unwrap();

    // Result is always correct: $80
    println!("Final balance: ${}", *balance.lock().unwrap());
}

What makes this special is that the Rust compiler enforces these rules - it won’t let you access shared data without proper synchronization.

The “Fast vs. Safe” Tradeoff

Historically, programming languages have forced developers to choose between safety and performance:

  • Safety-focused languages (Python, Java, Ruby) provide memory safety and abstractions that make programming easier but introduce runtime overhead through garbage collection, dynamic typing, and runtime checks.

  • Performance-focused languages (C, C++) offer direct hardware access and minimal runtime overhead but require programmers to manage memory manually, leading to potential bugs and security vulnerabilities.

This tradeoff seemed inevitable - you could have safety or speed, but not both at the same time.

Rust’s Solution: Zero-cost abstractions. Rust provides high-level features without imposing runtime overhead because most safety checks happen at compile time.

// This iterator chain will be optimized to efficient machine code
fn sum_even_numbers(numbers: &[i32]) -> i32 {
    numbers
        .iter()
        .filter(|&n| n % 2 == 0)
        .sum()
}

The above code looks high-level and expressive, similar to Python or other languages with functional programming features. However, Rust’s compiler transforms this into machine code that’s as efficient as hand-written, low-level C code with loops and manual optimizations. The safety guarantees don’t disappear at runtime - they’ve already been verified during compilation.

Rust achieves this through:

  • Moving checks from runtime to compile time
  • Avoiding hidden control flows or allocations
  • Allowing precise control over memory layout
  • Providing escape hatches for performance-critical code (unsafe blocks)
  • Eliminating the need for a garbage collector or runtime system

The result is a language that can be used for everything from operating systems and embedded devices to web services and command-line tools, with performance comparable to C/C++ but with modern safety guarantees.

The Null Reference Problem

Tony Hoare, inventor of the null reference, called it his “billion-dollar mistake” due to countless crashes and vulnerabilities that have resulted from it over decades of software development.

Null references plague most programming languages, causing some of the most common runtime errors:

The Problem:

// In Java
String text = null;
int length = text.length(); // NullPointerException at runtime!

// In C#
string name = GetName(); // Could return null
Console.WriteLine(name.ToUpper()); // NullReferenceException if name is null

// In JavaScript
const user = getUser(); // Could be undefined/null
console.log(user.address.street); // TypeError: Cannot read properties of undefined

These errors happen because:

  1. Any reference can be null/nil/undefined
  2. The compiler doesn’t force you to check
  3. The error only appears at runtime
  4. It often happens far from where the null was introduced

Rust’s Solution: Rust completely eliminates null references with the Option<T> type, which explicitly represents the concept of a value that might be absent.

fn find_user(id: u64) -> Option<User> {
    // Returns Some(user) if found, None otherwise
}

// Must handle both cases explicitly - compiler enforces this
match find_user(42) {
    Some(user) => println!("Found user: {}", user.name),
    None => println!("No user found"),
}

// Safer methods for common patterns
let name = find_user(42)
    .map(|user| user.name)
    .unwrap_or("Unknown".to_string());

// Chaining operations safely
let street = find_user(42)
    .and_then(|user| user.address)
    .and_then(|address| address.street)
    .unwrap_or("No street found");

The compiler ensures that you must handle the possibility of absence before using a value. This eliminates an entire category of runtime errors that plague other languages.

The “Dependency Hell” Problem

Anyone who’s worked on a non-trivial software project knows the pain of dependency management. Common issues include:

  • Version conflicts: Package A requires v1.0 of a library while Package B requires v2.0
  • Transitive dependency nightmares: Your dependencies have their own dependencies, creating a complex web
  • Reproducibility challenges: Builds working on one machine but failing on another
  • Installation difficulties: Complex setup procedures just to get started
  • Build system configuration: Maintaining makefiles, project files, or other build configs

Rust’s Solution: Cargo, Rust’s package manager and build system, which was designed from the ground up to address these issues:

# Creating a new project is trivial
cargo new my_project

# Adding a dependency is simple
cargo add serde --features derive

# Dependencies are tracked in Cargo.toml
# [dependencies]
# serde = { version = "1.0", features = ["derive"] }
# tokio = "1.28"

# Cargo.lock ensures exact same versions for reproducible builds

# Building is standardized
cargo build

# Running tests is consistent
cargo test

# Publishing to crates.io is straightforward
cargo publish

Cargo handles:

  • Semantic versioning to avoid breaking changes
  • Multiple versions of the same dependency when needed (no “DLL hell”)
  • Deterministic builds with lockfiles
  • Workspace support for multi-crate projects
  • Integrated documentation generation
  • Standardized testing framework
  • Benchmarking tools

This means you spend less time fighting with your build system and more time writing code. The community benefits from standardization, making it easier to contribute to projects since they all use the same tooling.