Your code won't compile. That's the whole point.

Your current mental model is probably: save the file, hit refresh or run the script, see what happens. The program is read line by line as it executes. If line 300 has a typo, you find out when line 300 runs — possibly in production, possibly at 3am.

Rust inserts a step. You save the file, then a program called rustc reads all of it, checks it, and translates it into machine code for your specific processor. Only then can it run. Nothing is interpreted, nothing is looked up by name at runtime, and there is no interpreter shipped alongside your code. You get a single executable file — that is what you deploy.

This is why Rust feels slow to write and fast to run. The compiler is doing work you used to do — by testing, by review, by getting paged. Expect to spend your first week arguing with it and your second week grateful for it.

The toolbox, in words you already know

PHP and Python hide memory from you completely, and that is usually a kindness. Rust does not, so you need one image in your head. Here it is.

The stack is a stack of trays in a canteen. You add a tray on top, you take a tray off the top, and that is all you can do. It's extremely fast because "where does this go" is never a question — it goes next. The catch: every tray must be a known, fixed size, decided before the program runs.

The heap is a large warehouse. You ask for space, someone finds a shelf big enough, and hands you back a shelf number. Slower, because searching takes time and the number has to be followed to reach the goods. But the size can be anything, and it can grow.

Now the key insight. That stack-side handle is small and copyable. The heap buffer is not. If two handles pointed at the same buffer and both tried to free it, you'd have a bug that has cost the industry billions. Every ownership rule you're about to learn exists to make that impossible without a garbage collector.

Every language must answer: when heap memory is no longer needed, who frees it? There are exactly three strategies in wide use, and you have been enjoying the second one.

Strategy three has no runtime cost at all. It is paid entirely at compile time, in your patience. That is the trade Rust asks you to make, and it's a genuine trade — not a free lunch and not a con.

Types are checked before the program exists

A type in Rust isn't documentation and it isn't a hint — it's a claim the compiler verifies. fn total(items: &[Order]) -> u32 guarantees that items is a list of orders and the result is a non-negative whole number. Not "should be". Cannot be otherwise. There is no TypeError at runtime because there is no runtime type to get wrong.

And nothing converts itself quietly. "5" + 5 is a compile error, not 10 and not "55". If you want a number from a string you ask for one, and you handle the case where it isn't one. This is the single biggest source of "why is Rust so verbose" — and the single biggest source of its reliability.

Immutable by default

let x = 5; creates a binding you cannot reassign. To allow change you write let mut x = 5;. Reversed from what you're used to, and deliberately so: the default is the safe one, and mut becomes a visible marker of where state changes. When you read Rust, mut tells you where to look for surprises.

There is no null

No null, no None lurking in a variable that claims to hold a user, no undefined. A value of type User is a user. If it might be absent, the type says so out loud: Option<User>, which you cannot use as a User until you've handled the empty case. An entire family of 2am bugs simply cannot be expressed.

Same story for errors. Rust has no exceptions. A function that can fail returns Result<T, E> — a value that is either the answer or the reason there isn't one — and ignoring it produces a warning. Failure becomes part of the signature instead of invisible control flow.

# Python — the danger is invisible
user = find_user(uid)
print(user.email)
# AttributeError, three weeks later

// the absence is in the type
match find_user(uid) {
    Some(user) => println!("{}", user.email),
    None => println!("no such user"),
}

Three questions. If any of them feel like a coin flip, the section above is worth a second pass — module 3 will be much harder without them.

Modules 1 and 2 get you writing. Modules 3, 4 and 5 are the ones people quit over — they're placed early and given the most room, because everything afterwards assumes them. Modules 6 to 9 replace habits you brought with you. Modules 10 to 12 are where Rust starts feeling expressive rather than restrictive.

Each module has an objective, an idea explained from intuition, a worked example, a glossary, one exercise, and a quiz. Do the exercise before revealing the solution — reading Rust and writing Rust are different skills, and only one of them is being tested by the quiz.

Install rustup from rust-lang.org/tools/install; it brings the compiler and Cargo with it. Then everything happens through Cargo, which does the job of Composer, pip, and your Makefile at once.

cargo new invoicer      # make a project (also runs git init)
cd invoicer
cargo check             # type-check only — fast, use constantly
cargo run               # build and run

You get Cargo.toml (your manifest) and src/main.rs. The presence of main.rs is what makes this an executable rather than a library — Cargo works by convention, so there's no build script to write.

Worked example: every part named

fn main() {
    let customer = "Renata";
    let mut items = 2;
    items = items + 1;

    println!("Invoice for {customer}: {items} items");
}

• fn main() — the entry point. Exactly one per executable. No file gets executed top-to-bottom the way a PHP script does; execution starts here.
• let customer = "Renata"; — a binding. No type written, because the compiler infers &str.
• let mut items — reassignable, because mut says so. Without it, line 4 is an error.
• println! — the ! means macro, not function. It is expanded into code at compile time, which is how it can check your format string before the program runs.
• Semicolons end statements, and braces define scope. Blocks are also expressions, which matters in module 2.

let counter = 10;
counter = counter - 3;

fn main() {
    let mut counter = 10;
    counter = counter - 3;
    println!("counter is {counter}");
}

Rust infers types wherever it can, so annotated code is rarer than you'd fear. But inference works forwards from evidence, not from hope — and it never invents a conversion. That second half is the adjustment.

Worked example: the conversions Rust won't do

let a = "5" + 5;              // no. text is not a number
let b: i32 = 4.5;             // no. that's an f64
let c = 3 + 2.5;              // no. i32 + f64 has no meaning
if 1 { println!("yes"); }   // no. 1 is not a bool

let quantity: i32 = "5".parse().unwrap();   // parse can fail; unwrap says "crash if it does"
let price = 3 as f64 + 2.5;                  // 5.5
let total = quantity as f64 * price;
if quantity > 0 { println!("{total}"); }      // a real comparison

Nothing was forbidden — you just had to say what you meant. .unwrap() is a beginner's placeholder meaning "crash if this failed"; module 8 replaces it with something you'd ship.

mut versus shadowing

let mut n = 5;
n = 6;
// n is i32, always was, always will be

let input = "42";
let input: i32 = input.parse().unwrap();
// second `input` is a different type

fn main() {
    let qty = "12";
    let unit = "4.25";

    let qty: f64 = qty.parse().unwrap();
    let unit: f64 = unit.parse().unwrap();

    let total = qty * unit;
    println!("line total: {total:.2}");
}

This is the concept. Everything difficult about Rust is downstream of it, and it takes about a week to stop tripping over. The good news: there are only three rules and they are short.

1. Every value has exactly one owner.
2. There can only be one owner at a time.
3. When the owner goes out of scope, the value is dropped — its memory freed.

The intuition: a physical document

Think of an owned value as a single paper contract, not a Google Doc. If you hand me the contract, you no longer have it — there's one copy and it's in my hands now. When I'm done, I shred it. That's ownership: assignment hands the thing over. Rust calls this a move.

Compare what you're used to: in Python, b = a makes a second label on the same object, both perfectly usable. In Rust, let b = a; for a heap-owning value makes b the owner and marks a as unusable, right there at compile time.

Worked example: moves, and the exception

let s1 = String::from("Bonjour");
let s2 = s1;                  // s1 moved into s2
println!("{s1}");             // error[E0382]: borrow of moved value

let a = 7;
let b = a;                    // i32 is Copy — a is still valid
println!("{a} and {b}");      // prints "7 and 7"

Why the difference? An i32 is four bytes on the stack with nothing on the heap, so duplicating it costs nothing and creates no cleanup question. Types like that implement a trait called Copy, and assignment copies them instead of moving. Integers, floats, bool, char, and tuples of those are Copy. Anything owning heap memory — String, Vec, your own structs by default — is not.

Functions take ownership too

fn main() {
    let note = String::from("paid");
    archive(note);              // note is moved in…
    // note is gone here — archive dropped it

    let kept = tag(String::from("draft"));  // …unless it's handed back
    println!("{kept}");          // "draft/reviewed"
}

fn archive(text: String) {
    println!("archiving {text}");
}                               // text goes out of scope → freed

fn tag(mut text: String) -> String {
    text.push_str("/reviewed");
    text                        // no semicolon: this is the return value
}

Passing by value into a function is a move, exactly like assignment. Returning a value moves it back out. This works, and for a day or two you'll write code that passes things in and returns them just to keep using them — a phase everyone goes through, and which borrowing ends.

fn main() {
    let label = String::from("invoice-88");
    let n = length_of(label);
    println!("{label} has {n} chars");
}

fn length_of(text: String) -> usize {
    text.len()
}

let n = length_of(label.clone());

let (label, n) = length_of(label);

fn length_of(text: String) -> (String, usize) {
    let n = text.len();
    (text, n)
}

let n = length_of(&label);

fn length_of(text: &String) -> usize {
    text.len()
}

A borrow is a reference: access to a value without owning it, written with &. When it ends, nothing is freed — the owner is still the owner. And there are exactly two kinds.

That's the whole rule, and it has a name worth remembering: shared XOR mutable. Many readers, or one writer. Never both.

Why the rule exists

Every PHP or Python developer has been bitten by this: you iterate over a list and modify it inside the loop, and the result is nonsense or a RuntimeError. That's the same hazard. A reader assumed things would hold still, and a writer moved them.

Rust turns that class of bug from a runtime surprise into a compile error — and the same rule, applied to threads, is what makes Rust's concurrency safe (module 12). One idea, two enormous payoffs.

Worked example

fn main() {
    let mut line = String::from("invoice");

    // two shared borrows at once — fine
    let a = &line;
    let b = &line;
    println!("{} {} {}", a, b, width(&line));

    // a and b are never used again, so their borrows have ended here

    append_ref(&mut line);      // now a unique borrow is available
    println!("{line}");           // "invoice-88" — line is still ours
}

fn width(text: &String) -> usize {
    text.len()
}

fn append_ref(text: &mut String) {
    text.push_str("-88");
}

Note let mut line: you can only hand out a &mut to something you own mutably. And at the call site you write &mut line explicitly — mutation through a borrow is never hidden from the reader.

let mut line = String::from("invoice");
let peek = &line;           // shared borrow starts
line.push_str("-88");        // needs a unique borrow → conflict
println!("{peek}");          // shared borrow still alive here

Read the last line of that error first. The borrow conflicts because peek is used after the mutation. Delete line 4 and the code compiles — a borrow lasts until its last use, not until the end of the block.

let mut v = vec![1, 2, 3];
let first = &v[0];
println!("{first}");   // last use of the shared borrow
v.push(4);            // fine — nothing is borrowed any more

// 1 · reads only → shared borrow
fn count_overdue(lines: &Vec<String>) -> usize { /* … */ 0 }

// 2 · changes the list in place → unique borrow
fn add_footer(lines: &mut Vec<String>) {
    lines.push(String::from("-- end --"));
}

// 3 · takes over and reuses the parts → ownership
fn into_report(lines: Vec<String>) -> String {
    lines.join("\n")
}

let mut lines = vec![String::from("a")];
for line in &lines {
    if line == "a" {
        lines.push(String::from("b"));   // E0502
    }
}

Lifetimes have a reputation. Most of it comes from one misunderstanding, so let's remove it before anything else.

Here's what they're for. This function is a disaster in the making, and every language has to deal with it somehow:

fn make_label() -> &String {
    let label = String::from("invoice-88");
    &label          // label is dropped at the closing brace…
}                   // …so this reference would point at freed memory

In C this compiles and you get a use-after-free — a security bug. In Python it can't happen, because the object is kept alive by the reference count. Rust takes a third path: it refuses, and explains that the return type needs to say where the borrowed data comes from.

Most of the time you write nothing

The compiler fills in the obvious cases — a set of rules called elision. You've already written lifetime-using code in module 4 without noticing:

// what you write
fn width(text: &str) -> usize { text.len() }

// what the compiler understands: one input reference,
// so any returned reference must come from it
fn width<'a>(text: &'a str) -> usize { text.len() }

Case one: two inputs, one returned reference

With two borrowed inputs, the compiler can't guess which one the result borrows from — so you say. Read <'a> as "call this relationship a":

fn longer<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

In English: "the returned reference is valid for as long as both inputs are". You have not changed any value's lifespan — you've told the compiler what to verify at every call site. If a caller keeps the result after one input dies, that caller gets the error, which is exactly right.

Case two: a struct holding a reference

struct Excerpt<'a> {
    text: &'a str,        // I don't own this; someone else does
}

fn main() {
    let article = String::from("Rust is a systems language.");
    let first = Excerpt { text: &article[0..4] };
    println!("{}", first.text);   // "Rust"
}

The <'a> declares: an Excerpt cannot outlive the text it points into. Drop article while first lives, and the compiler stops you.

The beginner's escape hatch, and it's a legitimate one: if lifetime annotations start multiplying in your code, that's usually a signal to store owned data instead. Use String rather than &'a str in your structs until you have a measured reason not to. You'll pay a small allocation and save hours. Nobody will judge you; experienced Rust developers make this choice constantly.

fn main() {
    let banner;
    {
        let name = String::from("Renata");
        banner = &name;
    }
    println!("{banner}");
}

fn main() {
    let banner;
    {
        let name = String::from("Renata");
        banner = name;          // moved out — banner now owns it
    }
    println!("{banner}");      // fine: the value left the inner scope
}

A struct is close to what you'd call a class without inheritance: named fields, and methods defined separately in an impl block.

struct Invoice {
    number: u32,
    total_cents: u64,
    paid: bool,
}

impl Invoice {
    // no `self` → an associated function, like a static constructor
    fn new(number: u32, total_cents: u64) -> Self {
        Self { number, total_cents, paid: false }
    }

    // &self → borrows, reads only
    fn total(&self) -> f64 {
        self.total_cents as f64 / 100.0
    }

    // &mut self → borrows uniquely, may change fields
    fn mark_paid(&mut self) {
        self.paid = true;
    }
}

fn main() {
    let mut inv = Invoice::new(88, 4250);
    inv.mark_paid();
    println!("#{} — {:.2} — paid: {}", inv.number, inv.total(), inv.paid);
}

Everything from modules 3 and 4 shows up in the method receivers. &self is a shared borrow, &mut self a unique one, and a bare self consumes the struct. You now know exactly what each means and why mark_paid requires let mut inv.

Enums are the part you'll actually miss later

In PHP or Python, "a payment is pending, or settled with a reference, or failed with a reason" typically becomes a class with three nullable fields, or a dict with a type key and an unwritten rule about which other keys are present. Both let you construct nonsense: settled and failed, with no reference.

A Rust enum is a closed set of variants, and each variant carries its own data. Nonsense becomes unwritable:

enum Payment {
    Pending,
    Settled { reference: String, cents: u64 },
    Failed(String),
}

fn describe(p: &Payment) -> String {
    match p {
        Payment::Pending =>
            "waiting on the bank".to_string(),
        Payment::Settled { reference, cents } =>
            format!("{:.2} settled, ref {reference}", *cents as f64 / 100.0),
        Payment::Failed(reason) =>
            format!("failed: {reason}"),
    }
}

Two things just happened that are worth pausing on. First, a Settled payment always has a reference — there is no path through your program where it doesn't. Second, match is exhaustive: add a Refunded variant next month and every match in the codebase that doesn't handle it fails to compile. The compiler hands you the complete list of places to update. This is the feature people miss most when they go back to a dynamic language.

# nothing stops this
p = {"type": "settled"}
p["reference"]   # KeyError

// won't compile — missing field
Payment::Settled { cents: 100 }

if let Payment::Failed(reason) = &payment {
    eprintln!("alert ops: {reason}");
}

let Payment::Settled { cents, .. } = payment else {
    return;      // must diverge: return, break, continue, or panic
};
// `cents` is in scope for the rest of the function

enum Doc {
    Draft,
    InReview { reviewer: String },
    Published { at: String },
    Rejected { reason: String },
}

impl Doc {
    fn is_public(&self) -> bool {
        matches!(self, Doc::Published { .. })
    }
}

Option<T> is just an enum — you already know how it works:

enum Option<T> {
    Some(T),
    None,
}

That's the whole thing. <T> means it works for any type — Option<u32>, Option<Invoice>. The power isn't in the type; it's in the fact that Option<Invoice> and Invoice are different types, so you cannot use one where the other is expected. The check you kept forgetting is now impossible to forget.

# Python: signature says nothing
def find(uid):
    return db.get(uid)   # or None

find(7).name             # fine until it isn't

// signature is honest
fn find(uid: u32) -> Option<Customer>

find(7).name           // error: no field `name`
                        // on `Option<Customer>`

Three tools, in the order you'll reach for them

let found: Option<u32> = lookup_discount("SPRING");

// 1 · a default, when absence is ordinary
let percent = found.unwrap_or(0);

// 2 · handle one case and move on
if let Some(p) = found {
    println!("discount {p}%");
}

// 3 · both branches matter
let message = match found {
    Some(0)  => "code valid, but no discount".to_string(),
    Some(p)  => format!("{p}% off"),
    None     => "unknown code".to_string(),
};

Note the second arm: patterns can match on values too, not only variants, and the compiler still checks you've covered everything. That's match earning its keep.

Transforming without unpacking

// Option<Customer> → Option<String>, no unpacking needed
let city = find(7).map(|c| c.city);

// keep it only if it passes a test
let big = find(7).filter(|c| c.orders > 10);

// each step may itself be absent — and_then flattens
let region = find(7).and_then(|c| region_of(&c.city));

// finish with a fallback
let label = city.unwrap_or_else(|| "unknown".to_string());

If you've used Python's if x is not None and ... ladders, or PHP's ?->, this is the same idea with the nesting removed. map applies a function if there's a value; and_then is for when your function also returns an Option.

struct User { name: String, nickname: Option<String> }

fn display_name(u: &User) -> String {
    u.nickname.clone().unwrap()
}

fn display_name(u: &User) -> String {
    u.nickname
        .as_deref()                       // Option<String> → Option<&str>, no clone
        .filter(|n| !n.is_empty())        // empty counts as absent
        .unwrap_or(&u.name)                // fall back to the real name
        .to_string()
}

fn display_name(u: &User) -> String {
    match &u.nickname {
        Some(n) if !n.is_empty() => n.clone(),
        _ => u.name.clone(),
    }
}

Rust has no exceptions. Nothing is thrown, nothing propagates invisibly, and there is no catch. A function that can fail says so in its return type:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

The consequence is worth stating plainly: you can see every failure point in a signature. No hunting for which of forty called functions might throw. And ignoring a Result produces a compiler warning — a discipline PHP and Python can't enforce.

The ? operator does the work

Handling errors by hand is verbose, and it was verbose in early Rust too. Then ? arrived. On a Result, it means: if this is Ok, unwrap it and carry on; if it's Err, return that error from the enclosing function immediately.

let text = match read_file(p) {
    Ok(t)  => t,
    Err(e) => return Err(e),
};

let text = read_file(p)?;

use std::fs;
use std::error::Error;

fn total_from_file(path: &str) -> Result<u64, Box<dyn Error>> {
    let text = fs::read_to_string(path)?;   // may fail: no file, no permission
    let mut total = 0;

    for line in text.lines() {
        if line.trim().is_empty() { continue; }
        total += line.trim().parse::<u64>()?;   // may fail: not a number
    }

    Ok(total)                            // success is explicit too
}

fn main() {
    match total_from_file("amounts.txt") {
        Ok(t)  => println!("total: {t}"),
        Err(e) => eprintln!("could not compute total: {e}"),
    }
}

Two different error types — a filesystem error and a number-parsing error — both propagate through the same ?. That works because Box<dyn Error> means "some error, I'm not being specific", and ? converts into it automatically. It's the right choice for application code and quick tools.

Read the body again and notice what it looks like: a straight line of happy-path logic, with ? marking each place something can go wrong. That's the same ergonomics as exceptions — every failure point is just visible.

fn sum_csv(line: &str) -> Result<i64, std::num::ParseIntError> {
    let mut total = 0;
    for field in line.split(',') {
        total += field.trim().parse::<i64>()?;
    }
    Ok(total)
}

fn sum_csv(line: &str) -> Result<i64, std::num::ParseIntError> {
    line.split(',')
        .map(|f| f.trim().parse::<i64>())
        .sum()          // sums Result<i64,_> into Result<i64,_>
}

This module exists because text is where PHP and Python developers lose the most time. In your languages a string is one thing that does everything. In Rust there are two, and the difference is ownership — which you now understand, so this will be quick.

let owned: String = String::from("Bonjour tout");
let literal: &str = "Bonjour tout";      // literals are always &str

let view: &str = &owned;                   // String → &str, free
let copy: String = literal.to_string();     // &str → String, allocates

// so: take &str, return String
fn shout(text: &str) -> String {
    text.to_uppercase()
}

shout(&owned);      // works
shout(literal);     // works — one signature, both callers

The rule that ends the confusion: parameters take &str, return values and struct fields use String. If you follow only that, ninety per cent of your string friction disappears.

Why text[0] is a compile error

This one offends people, so here's the honest reason. Rust strings are UTF-8, always. In UTF-8, a character takes between one and four bytes — é takes two, 😀 takes four. So "the character at index 0" and "the byte at index 0" are different questions, and only one of them is cheap to answer.

PHP's $s[0] gives you one byte, which mangles any accented text. Python 3 gives you a character, at the cost of a more complex internal representation. Rust refuses to guess, and makes you name which you want:

let s = String::from("café");

s.len();                          // 5 — bytes, not characters
s.chars().count();                // 4 — characters, costs a scan
s.chars().next();                 // Some('c') — the first character
s.chars().rev().collect::<String>(); // "éfac"
&s[0..3];                       // "caf" — byte range, panics if it splits a character

Vec and HashMap

use std::collections::HashMap;

let mut lines: Vec<String> = Vec::new();
lines.push(String::from("first"));
let nums = vec![10, 20, 30];       // vec! is the shorthand

nums[0];                       // 10 — but panics if out of range
nums.get(99);                  // None — the safe way

let mut stock: HashMap<&str, u32> = HashMap::new();
stock.insert("widget", 4);
stock.get("widget");            // Some(&4) — an Option, of course
*stock.entry("widget").or_insert(0) += 1;  // insert-or-update in one step

Note that .get() returns Option everywhere in Rust. Indexing with [] panics on a missing key or index — the same trade PHP makes with a notice and Python makes with KeyError, except here you have a checked alternative that's just as short.

fn total(xs: &[i32]) -> i32 { xs.iter().sum() }

let v = vec![1, 2, 3, 4];
total(&v);          // whole vector
total(&v[1..3]);    // just the middle — no copy
total(&[7, 8]);     // a fixed array

use std::collections::HashMap;

fn word_counts(text: &str) -> HashMap<String, usize> {
    let mut counts = HashMap::new();
    for word in text.split_whitespace() {
        *counts.entry(word.to_lowercase()).or_insert(0) += 1;
    }
    counts
}

A trait is an interface: a set of method signatures a type can promise to provide. If you've used PHP interfaces or Python protocols, you're most of the way there — with one significant upgrade. You can implement your trait for a type you didn't write, including types from the standard library.

trait Summary {
    fn headline(&self) -> String;

    // a default — implementors may override it or not
    fn preview(&self) -> String {
        format!("{} …", self.headline())
    }
}

struct Invoice { number: u32, cents: u64 }
struct Note { body: String }

impl Summary for Invoice {
    fn headline(&self) -> String {
        format!("Invoice #{} — {:.2}", self.number, self.cents as f64 / 100.0)
    }
}

impl Summary for Note {
    fn headline(&self) -> String {
        self.body.chars().take(40).collect()
    }
}

Two unrelated structs, no common ancestor, and no class hierarchy to plan. The trait is declared separately from both types, which is the piece that makes traits more flexible than interfaces: behaviour is bolted on, not baked in.

Generics: one function, many types

// "any T, as long as T implements Summary"
fn print_card<T: Summary>(item: &T) {
    println!("┌ {}", item.headline());
    println!("└ {}", item.preview());
}

// same thing, lighter syntax
fn print_card(item: &impl Summary) { /* … */ }

The : Summary part is a trait bound, and it's the whole idea behind Rust generics. In Python a duck-typed function hopes the argument has the method; here the compiler checks it, at the call site, for every type you ever pass. Unlike Java or C# generics, this costs nothing at runtime — the compiler generates a specialised copy of the function per concrete type.

Generic or dyn? The one distinction to learn

let items: Vec<Invoice> = /* … */;
// all one type. fastest possible calls.

let items: Vec<Box<dyn Summary>> = vec![
    Box::new(invoice),
    Box::new(note),      // mixed types!
];

The decision rule is simple: if the collection must hold different types, you need dyn. Otherwise use generics. A Vec<T> holds one type only — that's what makes it fast, and it's the constraint that sends people to dyn.

The traits you'll meet on day one

#[derive(Debug, Clone, PartialEq)] above a struct generates all three implementations. You will type it constantly — start with Debug on everything, since {:?} is your var_dump and your repr().

use std::fmt;

struct Money { cents: i64 }

impl fmt::Display for Money {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "{}.{:02}", self.cents / 100, (self.cents % 100).abs())
    }
}

Good news: this module is mostly recognition. If you've used Python generators or PHP's array_map, you already have the concepts. A closure is an anonymous function that captures its surroundings, written |x| x * 2. An iterator is lazy — it does nothing until something asks it for values.

let invoices = vec![4250, 0, 19900, 350];

let big_total: u64 = invoices
    .iter()                      // borrow each element
    .filter(|&&cents| cents > 1000) // keep the large ones
    .sum();                      // this line does all the work

let labels: Vec<String> = invoices
    .iter()
    .map(|c| format!("{:.2}", *c as f64 / 100.0))
    .collect();                  // and this one

Nothing happens in filter or map. They build a description. The final sum or collect — the consumer — drives the whole chain, touching each element exactly once. And because it all compiles to a single specialised loop, this is typically as fast as the for loop you'd have written, sometimes faster.

That last point is the one worth savouring: in Python, chaining map and filter costs you performance and you accept it for readability. In Rust the idiomatic version and the fast version are the same version.

Which iter? Ownership again

for x in &collection is .iter(); for x in collection is .into_iter() — which is why the second form makes the collection unusable afterwards. That surprises everyone once, and then never again.

let v = vec![3, 9, 4];

v.iter().any(|&x| x > 5);            // true
v.iter().all(|&x| x > 0);            // true
v.iter().find(|&&x| x % 2 == 0);      // Some(&4)
v.iter().position(|&x| x == 9);       // Some(1)
v.iter().max();                        // Some(&9)
v.iter().count();                      // 3
v.iter().enumerate();                  // (0, &3), (1, &9), …
v.iter().rev().take(2);                // 4, 9 — lazily

fn overdue_refs(lines: &[String]) -> Vec<String> {
    let mut out = Vec::new();
    for line in lines {
        if line.starts_with("OVERDUE") {
            out.push(line.to_uppercase());
        }
    }
    out
}

fn overdue_refs(lines: &[String]) -> Vec<String> {
    lines
        .iter()
        .filter(|line| line.starts_with("OVERDUE"))
        .map(|line| line.to_uppercase())
        .collect()
}

Sooner or later you'll need two parts of a program to share one value, and "exactly one owner" will be in the way. Rust's answer is a small set of wrapper types. You don't need to master them now — you need to recognise their names, so that when you meet one you know what problem it solves.

The two combinations you'll see in real code, and what they mean when you spot them: Rc<RefCell<T>> for shared mutable state in one thread, and Arc<Mutex<T>> for shared mutable state across threads. Each reads as "many owners" wrapped around "mutation allowed".

Fearless concurrency, concretely

Here's the claim that draws people to Rust: data races are compile errors. Not caught in review, not found by a race detector under load — rejected before the program exists.

Two marker traits do it. Send means a type is safe to move to another thread; Sync means it's safe to share by reference. You never implement them — the compiler works them out — but they're why Rc can't cross a thread boundary while Arc can. If you try, the error mentions Send, and now you'll know what it means.

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

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..3 {
        let counter = Arc::clone(&counter);   // a new owner, same value
        handles.push(thread::spawn(move || {
            for _ in 0..1000 {
                let mut n = counter.lock().unwrap();
                *n += 1;
            }   // guard dropped here → lock released, automatically
        }));
    }

    for h in handles { h.join().unwrap(); }
    println!("{}", *counter.lock().unwrap());   // always 3000
}

Always 3000. Not usually. There is no version of this program that misses an increment, and no version that forgets to unlock — the guard's Drop handles that on every exit path, including a panic. Compare the equivalent in a language where forgetting to release a lock is a thing that happens.

This page is scaffolding. It gives you the mental model in the order that hurts least, but you cannot learn Rust without arguing with the compiler yourself. The next step is a project small enough to finish.

A four-week plan that works

1. Week 1 — Rustlings. Small compiler-checked exercises. Perfect for making the ownership rules automatic rather than merely understood.
2. Week 2 — the book, chapters 1 to 10. You've now seen everything in them once, so this is consolidation rather than first contact. Read chapters 4 and 10 twice.
3. Week 3 — a command-line tool. Something you'd genuinely use: a log filter, a CSV summariser, a file renamer. Add clap for arguments and anyhow for errors. Finish it.
4. Week 4 — the book, chapters 13 to 17. Iterators, smart pointers, concurrency. Then rewrite week 3's tool now that you know more, and notice how much shorter it gets.

Leave async, macros and unsafe for month three. They aren't harder to read, but they're much harder to debug while ownership still takes conscious effort.

The official material, and what each is for

All of it is also available offline: rustup doc opens the whole set in your browser with no network. Worth knowing on a train.

The difficulty map, revisited

Now that the terms mean something, here's an honest ranking of what's still ahead — so you can recognise a genuinely hard thing as hard, rather than as evidence you're bad at this.

One last thing, and it's the most useful sentence on this page. When the compiler rejects your code, it is almost never being pedantic — it has found a question about your program that you hadn't answered yet. Read the error as a question. That reframe is what turns the first fortnight from a fight into a conversation.