The main branch contains the problems you are meant to fix
The title promises 100 exercises, and the repository organizes them across 8 numbered sections. You begin with syntax and a basic calculator, then build ticket types while learning ownership, traits, errors, collections, and lifetimes. The last 2 sections cover threads and asynchronous futures. Each exercise is its own Cargo package with instructions inside the source and tests that judge the learner's change. The course book supplies the concept before the code task.
This structure changes how you should read a red compiler result. Main is the worksheet, so unfinished types, todo!() calls, and code that demonstrates a borrow or Send error belong there. Finished versions for the 100 exercises live on the solutions branch. The recommended wr command checks the current exercise and keeps you from skipping ahead. Running Cargo at the workspace root asks Rust to compile every unsolved lesson at once, which is a different job.
What happened when we ran it
Our sandbox installed commit 57d145e in 2 seconds and added 128 packages. The checkout contained 349 files, about 5,963 source lines, and 1.7 MB of repository data. A whole-workspace build ran for 12 seconds and exited with code 101. The compiler stopped in the future package because an Rc value remained live across .await, so the future failed the Send bound required by tokio::spawn.
The root test command also exited 101, this time after 1 second. Compilation reached the locks package and failed with 2 errors and 4 warnings. The log tail showed unfinished ticket and id variables, an E0308 type mismatch, and could not compile locks. It did not produce passed or failed test counts, so there is no suite total to report for our run.
Both failures match visible prompts in the measured source. The future file says to make the code compile by reordering statements around the Rc and yield point. The locks store still returns Option<todo!()> and leaves both methods unfinished. That context explains the red result without turning it green. Our commands proved that the worksheet branch is not a buildable completed workspace.
A root Cargo build tests the worksheet state, while wr tests progress
The intended loop uses wr, a separate workshop runner maintained outside this repository. From the top-level directory, it checks the current exercise and advances after the learner's solution passes. The course recommends committing progress on a new branch so upstream changes can be pulled without losing work. That is more setup than opening a browser, but it gives each of the roughly 100 tasks an immediate compiler and test response.
There is 1 GitHub Actions workflow, though it does not run a root cargo build or cargo test. It builds the mdBook and downloadable formats, checks links and redirects, and runs the formatter. That choice avoids failing on intentional exercise gaps. It also means the public workflow does not show every unfinished package becoming solvable under the current stable compiler. The separate solutions branch is therefore important evidence when an exercise appears impossible rather than merely incomplete.
Four classroom days reach Tokio without assuming systems experience
Mainmatter designed the course for a 4-day classroom workshop, with each student moving at their own pace while an instructor answers questions. The welcome chapter assumes another programming language, but no systems programming or memory-management background. Self-study is supported through the browser, a downloadable PDF, the repository, and the solutions branch. The authors still recommend having a friend or mentor available when you get stuck.
That recommendation is realistic by section 7 and section 8. Issue 351 says a thread solution needs move before the course has explained it. Issue 352 points out that a Tokio example uses ? inside an async block returning (), while the solution uses unwrap. Issue 277 reports contradictory wording about sending a Mutex through a channel. These are teachable corrections, but a solo beginner may not know when the lesson, rather than their code, is at fault.
The CC BY-NC 4.0 license limits paid reuse
The README licenses the material under Creative Commons Attribution-NonCommercial 4.0. That allows sharing and adaptation under its conditions for noncommercial use, but it is not the usual MIT or Apache-2.0 software grant. A learner cloning the 1.7 MB repository for personal study has a clear path. A training company that wants to copy the book or exercises into a paid course should obtain permission or choose material with terms that fit the business.
Rustlings is the closest alternative for a compact exercise loop. Google's course fits instructor-led teaching and has an Apache-2.0 license. The Rust book is better when long explanations and larger projects help you learn, while Rust by Practice supplies another sequence of hands-on tasks. None makes this course redundant. The question is whether 100 tightly ordered compiler problems suit the way you learn and the way you may reuse the material.
Nine thousand five hundred eighty-three stars do not make every lesson settled
GitHub showed 9,583 stars, 2,181 forks, and 51 combined issues and pull requests. An issue-only search returned 30 open issues. The repository was last pushed on June 28, 2026, and a new learner report arrived on September 12. There are no GitHub release tags. That pattern describes a popular course with continuing learner feedback, rather than a versioned Rust library whose health can be judged from release cadence.
Choose it for the small feedback loop: read one concept, change one package, and let Rust object to the exact mistake. Our 12-second build failure is useful evidence of the repository's teaching state, provided you do not mistake the root workspace for the finished product. Install wr, work on your own branch, and consult the solutions branch only after the current compiler message has stopped teaching you something.