Complete Rust Tutorial

Rust's reputation for difficulty comes from a single unusual demand: it asks you to state, in the type system, facts about your program that other languages leave implicit. Who owns this data. How long this reference is valid. Whether two threads may touch it at once. Nothing about those questions is new — C programmers answer them constantly, they just answer them in comments and in their heads.

What Rust adds is a compiler that checks the answers. The borrow checker is not an obstacle course; it is a proof assistant that refuses to compile a program whose memory story does not add up. Once you stop trying to satisfy it and start letting it tell you what your design actually implies, the error messages become the most useful design review you will get from a tool.

Ownership in three rules

Everything else in Rust's memory model follows from three statements. Each value has exactly one owner. When the owner goes out of scope, the value is dropped. There may be any number of shared references or exactly one mutable reference to a value at a time, never both.

That third rule is the one that generates the famous errors, and it is also the one that buys the most. It makes data races impossible by construction, because a data race requires two aliases where at least one writes — precisely the combination the rule forbids. Rust's thread safety is not a runtime feature; it is this rule applied across threads.

fn main() {
    let s = String::from("forge");
    let t = s;                 // move: s is no longer valid
    // println!("{s}");        // error[E0382]: borrow of moved value

    let a = String::from("forge");
    let b = a.clone();         // explicit copy, explicit cost
    println!("{a} {b}");       // both valid

    let mut v = vec![1, 2, 3];
    let first = &v[0];         // shared borrow starts
    // v.push(4);              // error[E0502]: cannot borrow as mutable
    println!("{first}");       // shared borrow ends here (NLL)
    v.push(4);                 // now fine
}

Lifetimes annotate what was always true

A lifetime parameter does not change how long anything lives. It describes a relationship the compiler cannot infer: this returned reference borrows from that argument, so it cannot outlive it. Most functions need no annotation because elision rules cover the common shapes; you are asked only when the answer is genuinely ambiguous.

When you hit a lifetime error that seems impossible to satisfy, the useful reframing is that the compiler has found a real question your design has not answered. Frequently the honest answer is that the value should be owned rather than borrowed, and returning an owned String instead of a &str is not a defeat — it is the design the data flow actually wanted.

Errors are values, and that changes how you design

Rust has no exceptions. A function that can fail returns Result<T, E>, and the caller cannot ignore it without saying so. The ? operator makes propagation a single character, so the ergonomics match exceptions while the signatures stay honest — you can see from the type which functions can fail.

The practical split in real codebases: libraries define concrete error enums so callers can match on specific cases; applications use a boxed, context-carrying error type because they mostly want to add context and bubble up. Mixing that up — an application enumerating every error variant, or a library erasing its error type — is the most common ergonomics mistake in Rust projects.

use std::fs;
use std::num::ParseIntError;

#[derive(Debug)]
enum ConfigError {
    Io(std::io::Error),
    BadPort(ParseIntError),
}

impl From<std::io::Error> for ConfigError {
    fn from(e: std::io::Error) -> Self { ConfigError::Io(e) }
}
impl From<ParseIntError> for ConfigError {
    fn from(e: ParseIntError) -> Self { ConfigError::BadPort(e) }
}

fn load_port(path: &str) -> Result<u16, ConfigError> {
    let text = fs::read_to_string(path)?;   // io::Error -> ConfigError
    let port = text.trim().parse::<u16>()?; // ParseIntError -> ConfigError
    Ok(port)
}

Where Rust is the right tool, and where it is not

Rust earns its learning curve where a wrong answer is expensive and the work is long-lived: systems software, network services under real load, command-line tools that must start instantly, WebAssembly, embedded targets, and the performance-critical core of a larger application in another language.

It is a poor trade for exploratory data work, throwaway scripts, and prototypes whose shape will change five times before anyone decides what they are. Rust makes you settle ownership questions up front; that is exactly what you want in a service that will run for five years and exactly what slows you down in code that will not survive the week.