How to learn Rust

This stage is not about comfort with syntax; it is about training yourself to predict which code moves, borrows or copies. It sits first because every later concept builds on it, and because delaying it is the single most common reason people quit Rust.

• Move semantics for non-Copy types
• Copy vs Clone traits and when each applies
• Immutable and mutable borrows, including borrow checker rules
• String vs &str and when each is used
• Slices and references into owned data
• The compiler error messages E0382, E0502 and E0506
• Shadowing and its interaction with ownership

You can now: Write a function that takes a String, returns its length and still lets the caller use the original afterwards, without cloning, by borrowing correctly.

Rust's type system is doing ownership work everywhere. This stage is where you stop fighting it and start using it. Enums and pattern matching come here because they are the natural way to model data that can be in one of several states, which is most data.

• Structs with owned and borrowed fields
• Enums with data, including Option and Result
• Pattern matching with match, if let and while let
• The Result type and the ? operator
• Deriving Debug, Clone, PartialEq and when not to derive
• Generic functions and structs with trait bounds
• The Copy trait and why some types do not implement it
• Iterators and the Iterator trait

You can now: Write a small CLI programme that reads a file path from argv, returns Result from main, and handles a missing file with a match on the error type, not just a panic.

Most learners meet lifetimes as a compiler complaint and never get past it. This stage is about reading lifetime elision rules and writing function signatures that express the actual relationship between inputs and outputs. It sits after ownership because lifetimes are just ownership over time.

• Lifetime elision rules in function signatures
• Explicit lifetimes in structs that hold references
• Lifetime subtyping where one reference outlives another
• Writing functions that return references into arguments
• The difference between 'static and long-lived, and why string literals are 'static
• Lifetime errors E0495 and E0106
• Covariance and contravariance in practice, without the words

You can now: Write a struct that holds a &str field and a function that returns the longer of two &str arguments, with explicit lifetimes, and explain why the compiler accepts it.

Rust's rules around interior mutability and shared ownership are where the borrow checker meets real programmes. This stage is about Rc, RefCell, Arc and Mutex, and about knowing which one you need without guessing. It sits after lifetimes because these types exist to work around the rules you have just learned.

• Rc and Arc for shared ownership
• RefCell and interior mutability
• Mutex and poisoning
• Channels for sending data between threads
• Combining Arc and Mutex, and why the combination is so common
• Send and Sync traits and what they guarantee
• Choosing between Rc and Arc by whether threads are involved
• The deadlock that Rust does not prevent

You can now: Build a multithreaded programme where several threads push to a shared Vec via Arc<Mutex<Vec<T>>>, and explain why the Mutex is inside the Arc and not the other way round.

Rust's error handling is not about try-catch; it is about making failure a type. This stage is where you learn the patterns that make Rust code readable: custom error types, the thiserror and anyhow crates, and when to use which. It sits here because you need the previous stages to understand what a good error type looks like.

• Custom error types with the Error trait
• The thiserror crate for deriving Display and Error
• The anyhow crate for application-level errors
• When to use a library error enum vs anyhow
• The From trait for converting between error types
• Panicking vs returning Result, and when each is right
• The unwrap and expect methods and why they are for prototyping only
• The map_err and or_else combinators

You can now: Rewrite a small CLI tool that previously used unwrap to use a custom error enum with thiserror, and handle a missing file, a permission error and an invalid UTF-8 path as three distinct error variants.

Rust's async is not like JavaScript's. It is a set of building blocks, not a runtime, and you must understand what the executor is doing before async code makes sense. This stage is late because it builds on ownership, lifetimes and error handling.

• Futures and the Future trait, and why they are lazy
• The Tokio runtime and what it does
• async fn and await, and how they desugar
• The Send constraint on futures and why it matters
• Choosing between threads and async for a task
• The select! macro and timeouts
• Streams and the Stream trait
• The async and await syntax and what it does not do

You can now: Write a small async programme that fetches two URLs concurrently with Tokio, waits for both with a timeout, and prints each result or a timeout error, without blocking the thread.

The final stage is about moving from toy programmes to the code other people write. You need to read crate documentation, understand public APIs, and contribute small fixes. This is where you find out whether you actually know Rust or just memorised syntax.

• Reading crate documentation and understanding the public API
• Cargo workspaces and feature flags
• The borrow checker in the context of a large codebase
• Writing tests with the #[test] attribute and assert!
• Clippy and rustfmt and why they are not optional
• Reading and understanding the standard library's source for small types
• Contributing a small fix to a real crate

You can now: Pick a small crate on crates.io with fewer than 500 lines, read its source, and submit a pull request that fixes a documentation error or adds a test, and get it merged.