Learn Rust Programming

Learn what Rust is, why it matters, and write your first Rust program.

Learn about variables, mutability, constants, and shadowing in Rust.

Get Rust and Cargo running on macOS, Linux, or Windows in a couple of minutes, plus the one editor extension that makes everything easier.

Create your first real Rust project with Cargo, understand the files it generates, and learn the handful of commands you will type every single day.

A practical tour of integers, floats, booleans, characters, tuples, and arrays — and how Rust quietly figures out most of this for you.

Write functions with parameters and return values, and learn the one quirk — expressions versus statements — that trips up almost everyone coming from another language.

Branch and repeat with if, loop, while, and for — and get a first taste of match, the pattern-matching tool that Rust developers reach for constantly.

A short, practical look at how Rust developers comment code — including doc comments, the neat trick that turns your comments into a real documentation website.

The single idea that makes Rust different from every language you have used before — explained without the jargon, so it actually sticks.

How Rust lets you use a value without taking it over: immutable and mutable references, the borrowing rules that rule out data races at compile time, and why dangling pointers simply cannot exist in safe Rust.

The type that turns a whole class of "the data changed underneath me" bugs into compile errors: string slices, range syntax, and why &str shows up absolutely everywhere in idiomatic Rust.

Bundle related data into your own named types — plus the one thing about struct update syntax that quietly catches almost everyone off guard the first time they use it.

Give your structs behavior, not just data: how impl blocks and &self work, why Rust lets a method share a name with a field, and what that mysterious :: in String::from has meant all along.

Model data that can be one of several different things — and meet the enum that quietly eliminates an entire category of bugs other languages still ship every day: Option<T>, Rust’s replacement for null.

The feature that makes enums worth having: match arms that check a value and pull its data out in the same breath, the exhaustiveness check that catches forgotten cases at compile time, and the shorthands — if let and let-else — that keep simple checks simple.

Real techniques for living with Option day to day — unwrap, expect, map, and friends — plus Result, the sibling type Rust reaches for whenever something can fail and the reason matters. The moment error handling in Rust starts clicking.

The collection type you will write more than any other in Rust: how Vec<T> grows on the heap, two ways to read from it with very different personalities, why pushing to one can make the borrow checker speak up, and the clean trick for storing more than one type inside it.

Why a type that looks this simple turns out to be the most genuinely subtle one in the language: building and combining strings, and the real reason Rust refuses to let you write s[0] — a refusal that is protecting you from a bug you have not met yet.

Rust's third everyday collection — and the one that finally answers the question the strings lesson left hanging: do I already have one of these, and what was it paired with? Insert, look up, iterate, and the one-line trick that turns counting into a one-liner.

The single judgment call that "being good at error handling" actually comes down to — when your code hits trouble, should it hand the problem to its caller, or stop right where it stands? A close read of a real panic message, the one case where .expect() is genuinely the right call, and the elegant trick of building a type that simply cannot hold an invalid value.

The single character that turns "if it worked, keep going — if it failed, stop and hand the error upward" from a paragraph of match arms into one keystroke. Exactly what ? does under the hood, why it only works inside certain functions (and the one compile error that explains why), and the pleasant surprise that the very same operator works on Option too.

The lesson where error handling stops being something Rust hands you, ready-made, and starts being something you design yourself — building an enum that names every distinct way one specific function can fail, giving it a human voice with a method you already know how to write, and an honest preview of the three traits that would make it feel truly native (and exactly why you will want to learn them, starting next lesson).

The lesson where a piece of syntax you have been reading fluently since lesson 14 — those angle brackets wrapped around a single capital letter — finally gets a full name and a proper explanation. What generics actually are, why Option<T>, Result<T, E>, and Vec<T> all secretly are them, how to write your own generic functions, structs, and methods, and the genuinely delightful fact that none of it costs you a single nanosecond at runtime.

The lesson where three separate mysteries — last lesson's PartialOrd bound, the #[derive(...)] attribute you have been writing without question since the structs lesson, and CountError's slightly awkward .map_err() calls from two lessons back — turn out to be the exact same idea, seen three times from three different angles. What a trait actually is, how default implementations and derive both quietly rest on it, and the genuinely satisfying moment two .map_err() calls disappear for good.

The lesson that answers the question the previous one ended on: a function takes two references and returns one of them, and for the first time in this course, the compiler refuses to guess which. The missing lifetime specifier error, read in full and explained in plain English; what 'a actually does (and the one big misconception about what it does NOT do); and the quiet elision rules that explain why every function before this one never needed any of this at all.

The lesson where every earlier lesson's code becomes the material. Write #[test] functions for largest (generics), CountError's new Display impl (traits), and Guess (panic vs Result) — and discover along the way that a failing assert_eq! is just panic! from a few lessons back, triggered by a macro instead of by hand. #[test], #[cfg(test)] modules, assert_eq!/assert_ne!/assert!, #[should_panic], cargo test, and Result-returning tests with ?.

The lesson two earlier lessons have been pointing toward: lesson 16 promised a proper explanation of |x| expression, and last lesson promised "the other way to make a thing to call later." Both arrive here. What a closure actually is, the four syntax forms it can take, and the one thing it can do that an ordinary fn never can: reach out and capture a variable from the code around it. Revisits or_insert_with and unwrap_or_else as closures in disguise, covers sort_by_key and the move keyword, and names Fn/FnMut/FnOnce ahead of the iterators lesson.

The payoff for everything closures just taught — and the reveal that for loops, since the control-flow lesson, were always iterators wearing a disguise. Rewrite a hand-written loop as .into_iter().filter().map().collect(), then look underneath: the entire Iterator trait is one method, next() -> Option<Self::Item>, with everything else — filter, map, collect, sum, max — built on top of it as default implementations. Covers adaptors vs. consuming methods, and ties Fn/FnMut/FnOnce from last lesson to real signatures.

Two loose threads finally tie together: the panic-vs-Result lesson's private value field inside Guess ('exactly how Rust draws and enforces that boundary is its own lesson'), and the Hello Cargo lesson's [package] section in Cargo.toml. The mod keyword for grouping code, Rust's default-private visibility and the pub keyword that opts out of it, use for shortening the paths you've been writing since std::collections::HashMap (and what use super::* in the testing lesson actually meant), splitting a module into its own file, and precise definitions of crate and package.

Every file this course has opened — hello.txt, username.txt, count.txt — has had its name hardcoded directly into the source. Today that changes: std::env::args reads what was typed on the command line (an iterator, fed straight into the collect from the iterators lesson), std::env::var reads environment variables, and fs::write finally covers the other half of file I/O. Closes with Option::map and unwrap_or, tying Option directly to the Iterator methods from last lesson and the closures lesson before that.

Lesson 4 added one external crate, rand, and used it once before derive, traits, or modules meant anything yet. This lesson adds the second: serde, plus its JSON half, serde_json. #[derive(Serialize, Deserialize)] is #[derive(Debug)] from the structs lesson, extended to a crate you did not write — turning any struct into a JSON string with serde_json::to_string and back with serde_json::from_str. Combined with fs::write and fs::read_to_string from the last lesson, a whole Vec<T> can be saved to disk and loaded back as one JSON file, with serde_json::Error sliding into Box<dyn Error> the same way every other error type has since the traits lesson.

The capstone of the core curriculum: a real, working command-line to-do list, task_cli. A Task struct with #[derive(Serialize, Deserialize)] from the serde-and-json lesson, load_tasks and save_tasks built from fs::read_to_string/fs::write and the env::var-style match from files-and-io, and a main() that dispatches add/list/done from env::args using the exact args.get(1).map(String::as_str) pattern the files-and-io lesson ended on. The list command is the iterators lesson's .enumerate() section, verbatim. Almost nothing new — everything used. Closes with a course-wide recap and an honest preview of the two ADVANCED sections ahead.

Twelve lessons ago, Box<dyn Error> was introduced as "reads, for now, as some kind of error, built from an idea waiting for you further down this course." The traits lesson explained the dyn half: any type at all, decided at runtime. It never explained the Box. This lesson finally does: dyn Error has no size the compiler can know in advance, and Box<T> is always the same fixed size no matter what is inside, which is the entire reason Result<(), Box<dyn Error>> compiles. From there: Rc<T> for sharing read-only access to the same heap data from multiple owners, where Rc::clone is a counter bump rather than the ownership lesson's deep-copying clone, RefCell<T> for mutating through a shared reference by checking the borrowing rules at runtime instead of compile time (and panicking on purpose when they are broken), and Rc<RefCell<T>>, the shared-mutable-state shape the next lesson reaches for again across threads.

The smart-pointers lesson ended by asking what happens once "multiple owners" means "multiple threads." Here is the answer: thread::spawn runs a closure on a real OS thread, and JoinHandle::join waits for it. Spawning a thread that touches a variable from main without move produces a real compiler error - "closure may outlive the current function" plus a note about outliving 'static - that is the closures lesson's move keyword and the lifetimes lesson's 'static prediction, both arriving at once. From there, std::sync::mpsc channels move ownership of values between threads one at a time, and Receiver<T> turns out to implement Iterator, so a spawned thread can stream results back with an ordinary for loop. Closes by previewing Arc<Mutex<T>>, the thread-safe cousin of last lesson's Rc<RefCell<T>>.

The smart-pointers lesson promised it and the fearless-concurrency lesson named it: this lesson finally builds Arc<Mutex<T>>, the thread-safe replacement for Rc<RefCell<T>>. Starts by trying to send an Rc across a thread anyway and reading the real compiler error - "Rc<i32> cannot be sent between threads safely... the trait Send is not implemented" - which reuses thread::spawn's exact F: Send + 'static bound from the previous lesson's error. From there: Arc as Rc with an atomic counter, Mutex as RefCell's thread-safe cousin (.lock() instead of .borrow_mut(), returning a Result instead of panicking), a ten-thread counter that always prints Result: 10, and what that Result is actually for - a real lock-poisoning panic, captured live. Closes the Smart Pointers and Concurrency section by introducing Send and Sync by name.

Smart Pointers & Concurrency covered Rust's model for doing many things at once, on real OS threads. This lesson covers the other kind of "at the same time": waiting on many things at once - network calls, timers, file reads - using async/await and the tokio runtime, an external crate (#[tokio::main]) since the standard library deliberately ships no executor. Two nearly-identical programs make the whole idea concrete: awaiting two 100ms/150ms waits back to back takes about 250ms, the sum - but tokio::join!-ing the same two futures takes about 150ms, the longer one - on a single thread, with no std::thread::spawn involved. Closes with tokio::spawn, async's answer to thread::spawn from the fearless-concurrency lesson, and why tasks scale to hundreds of thousands where OS threads can't.

Lesson 1's very first code example carried a one-line aside about println! - "a macro (note the !)" - never explained since, even as vec!, format!, write!, assert_eq!, panic!, and last lesson's tokio::join! piled up. This lesson finally explains it, starting from vec![], vec![1, 2, 3], and vec![5; 3] - three argument shapes no ordinary function could have - through macro_rules! arms (mirroring match), $x:expr captures (and the "sealed unit" precedence behavior that protects against C's classic macro bugs), repetition with $(...),* to reimplement a tiny vec!, and a recursive multi-arm my_min! whose entire expansion happens at compile time - the same zero-cost promise as generics' monomorphization, for syntax instead of types.

The last lesson, and it teaches no new syntax. First, a look back: the threads that ran the length of this course - lesson 22's Box<dyn Error>, lesson 27/25's move and static-lifetime closures, lesson 33's Arc<Mutex<T>> preview, and lesson 1's very first ! - each picked up exactly when it mattered, because almost nothing here was taught in isolation. Then, forward: cargo clippy and cargo fmt, two commands that belong in every project from here on; a single unsafe block - raw pointers, dereferenced - the only unsafe code this course will ever show, named back in lessons 20 and 35 but never explained until now; and a map of the wider ecosystem (clap, anyhow, thiserror, reqwest, axum, rayon) showing which lesson prepared you for each. Closes with a final project extending lesson 32's task_cli, and a callback to lesson 9's "the compiler is teaching you."