A learning plan

This path assumes that you have programmed in another language and are new to Rust. Each session takes roughly 45–60 minutes. Two or three sessions a week makes a four-to-five-week plan, but daily practice is fine. Use the acceptance conditions, rather than the calendar, to decide when to move on. If programming itself is new, split stages 01 and 02 into two or three sessions each.

A repeatable session

1. Predict — five minutes. Before running the code, describe the output or compilation result in your own words.
2. Write and run — twenty minutes. Read the smallest example, change one thing, and run it.
3. Break and investigate — fifteen minutes. Read the error and test a hypothesis with a breakpoint or a focused test.
4. Explain — five minutes. Explain why the result occurred. If the explanation is uncertain, return to a smaller example.
5. Record — five minutes. Save the observed result and your next question in labs/rust/docs/progress.md.

The first ten stages

The linked lesson files live in the private Kumyu repository alongside runnable examples. Clone the repository to work through the code locally.

Stage	Topic and work	Acceptance condition
01	Cargo, main, variables, functions; write a greeting in ex01	Change and execute code, and read a failed test
02	Types, mut, if, for, expressions and statements in ex02	Explain the input and return types
03	String, move, Copy, clone, and drop	Explain move versus copy with a diagram and code
04	&, &mut, &str, and slices in ex03 and ex04	Keep the original value through borrowing, and explain the period during which a reference is used
05	Compiler diagnostics, LLDB, panic, and a boundary bug	Test a hypothesis at a breakpoint and pass three focused tests
06	struct, enum, match, Vec, and Option in ex06	Represent states and the absence of a value through types
07	Result, ?, I/O, and exit codes in ex05	Return failures to the caller without depending on panic
08	impl, traits, generics, iterators, and modules	Express a shared behavior with a trait and compare a loop with an iterator
09	Read and extend mini-grep	Extend arguments, file reading, searching, and presentation as distinct responsibilities
10	Requirements, regression checks, formatting, Clippy, and reflection	Explain your CLI with reproducible steps and relevant tests

The final exercise

Add --ignore-case to mini-grep, and optionally add --count next. Start with the standard library.

• Preserve ordinary search results and line numbers.
• Specify case handling, argument order, and the exit code for a search with no match before implementing them.
• Try a successful search, no match, an empty file, invalid arguments, and a missing file.
• Keep your own tests, executed examples, and README instructions together.

The starting CLI is implemented. The extension exercises deliberately have no supplied solution. Finishing means that you wrote and observed the behavior yourself.

Use a diagram, then run the corresponding code

The ownership and debugging simulations are available at /en/rust/visuals/index.html. They work without network access after loading.

• Ownership: compare move, clone, and Copy, followed by the constraints on shared and mutable borrowing.
• Result: observe the branch from input into Ok or Err.
• Debugging: change the end of a half-open range and predict whether the final element is processed.

These are simplified explanatory models. They do not compile Rust in your browser. When a new question appears, pair the diagram with a ten-to-twenty-line Rust experiment on the same topic.

Continue through one product

Once you can explain the foundations, continue to stages 11–30. Grow one work-log product, Trail, from CLI to storage, web interface, jobs and recovery, then maintenance and distribution.

Trail v0 is runnable. Each stage specifies work, exercises, checks, and acceptance conditions. Connect these activities to the mental models.

Do not try to memorize everything at the start. Study asynchronous execution after persistence and synchronous I/O. Treat unsafe as a specialist branch that requires an observed need.

Why acceptance conditions matter

Choose the next lesson by whether you can reproduce and explain the previous small task. In ownership, memorizing vocabulary is insufficient: use short code and observed output to explain where a value moves and when a borrow is enough. A failed compilation is evidence too. Read the first diagnostic lines, reduce the example, and record what changed before and after your edit.

Introduce few concepts at each stage. Predict, run, observe an output or error, and explain it in your own words. This cycle prepares you to break later persistence and asynchronous behavior into types, owners, and failure paths. Record questions you cannot yet answer alongside commands that passed. They are inputs to your next experiment.

A diagram is no substitute for the compiler. Predict the relationship visually, execute the corresponding small Rust program, and revise the hypothesis when the results differ. Include this loop in your completion condition.

At every stage, connect changed lines, executed commands, and observed results. Returning to the same problem later should give you a reproducible explanation. Build understanding gradually from small, observable pieces of evidence.

Read the relevant chapter of The Rust Book or Rust By Example when a concrete question appears; a complete cover-to-cover reading is not a prerequisite.

The curriculum sources and exercises live together in labs/rust in the private Kumyu repository. Clone it to your own environment and read the lesson and runnable example from the same revision.

2024–2026: learn the compiler feedback loop, not a frozen syntax list

Rust’s 2024 project goals named the 2024 Edition, a better async experience, and progress toward stable Rust for Linux as flagship work. Rust 1.85.0 made the 2024 Edition stable in February 2025. This matters to the first ten stages because an edition is an opt-in compatibility boundary: a new project should declare the intended edition deliberately, while an existing project should migrate with cargo fix --edition and review the diff rather than assuming an automatic rewrite is a design review.

Run this focused experiment after stage 07. Create a scratch crate with edition = "2024"; add a tiny unsafe extern declaration only as a compile-time exercise, then remove it. Separately write an async || closure that borrows a local value and compare it with || async { ... }. Record the compiler diagnostic, the exact toolchain from rustc --version, and what your code owns at the await point. The objective is not to collect new syntax: it is to make the compiler's boundary visible.

The official Rust blog listed Rust 1.99.0 on 2026-10-01, inside this article's current check window. It is a current release fact, not a reason to change every lesson. Use rustup update stable, read its release notes before changing the workspace, and run the established exercises on the pinned toolchain.

AI context does not change the acceptance condition. Google's 2026-10-01 Argon announcement says its C/C++-to-Rust migrations receive automated and manual auditing, emulation testing, and review before production. The linked r/rust discussion is community reaction, not independent validation. For a beginner, use an assistant to propose a ten-line counterexample, then predict, compile, and explain it yourself. Do not accept a generated ownership explanation until the corresponding small program and test demonstrate it.