Broken exercises are the teaching method
Rustlings asks you to fix Rust files that deliberately fail to compile. Its usage guide points you toward TODO and todo!() markers, with hints available when you get stuck. That gives a learner an immediate job: make this particular program work. The distinction matters when reading our lab result, because the project's own test command also failed. Expected exercise errors and a failed maintainer suite are different findings.
I'd use Rustlings alongside the Rust Book, as the project recommends. It gives you a reason to stop reading and type something that the compiler can challenge. If you already know another language, that small assignment can expose assumptions that survive a page of explanation. A passing exercise still answers a narrow question. You have made that file satisfy its checks, not demonstrated that you can design a Rust application.
What happened when we ran it
Our Rustlings sandbox installed commit bc8e511 in 5 seconds, recording 67 dependencies, and built it successfully in 31 seconds on October 14, 2026. The test step then failed with exit 101 after 24 seconds. The supplied aggregate was 20 passed and 6 failed out of 26. That result gives source contributors something specific to reproduce, even though the earlier setup steps succeeded.
The tail names init, run_compilation_success, and run_test_success as failures in an integration-test result reporting 5 passed and 3 failed. It also says the fixture tests/test_exercises/exercises/test_success.rs ran with errors. That smaller result does not account for the entire aggregate on its own. Cargo recommends rerunning --test integration_tests, but the excerpt does not show the underlying diagnostic needed to explain why those cases failed.
Our recorded configuration had 3 CPUs, 12 GB of RAM, and image label lab-rust:1. The label does not prove the compiler or operating-system version. The checkout contained 292 files, about 12,092 source lines, and occupied 0.5 MB. The scan found 2 CI workflow files and a tests directory, with no Dockerfile. These are repository observations, not a measurement of how quickly a beginner learns or whether every exercise behaves correctly.
The failed cases deserve investigation before an instructor freezes this revision into a workshop image. Their names concern initialization and successful execution, operations a class will depend on. But the tail cannot tell us whether the failure comes from the toolchain, the sandbox, or the code. Keep the successful build and failed suite in the same decision. Neither cancels the other.
You need a local Rust toolchain before the first exercise
The setup guide requires Rust and Cargo, then uses cargo install rustlings and rustlings init. It calls out GCC for linking on Linux and Xcode developer tools on macOS. Windows users get a recommendation for Windows Terminal. These are concrete reasons to arrange a laptop beforehand if your alternative is a course that runs entirely in a browser.
No account or hosted AI credential appears in that standard workflow. The work is editing local Rust files and checking them with local tools. Setup documentation also explains the Cargo binary-directory PATH problem and how to open offline documentation through rustup. Those details make it a practical study companion once the machine is prepared. Our measured five-second installation is not a promise about downloading Rust or preparing a fresh student's computer.
Automatic reruns have a documented manual fallback
The usage guide says watch mode reruns the current exercise after file changes. If detection fails, rustlings --manual-run lets you request a rerun with r. The same guide asks bug reporters to identify containers or virtual machines, including WSL. That is a documented fallback, not evidence that file watching caused our integration failures.
Exercise-list controls let you revisit or reset work. For self-study, that makes it possible to return to an earlier mistake after the answer feels obvious. For a workshop, verify the edit-to-feedback loop in the exact environment participants will use. A compiler available in one terminal does not establish that an editor's changes will trigger the runner in another environment.
September code activity and October discussion show continued attention
GitHub records the last push as September 29, 2026. Its October issue list includes a pull request updated on October 14 about writing solutions after multiple exercises are completed. That proposal describes its own reproduction steps. It is evidence of current discussion around the learner workflow, not a confirmed explanation for the unrelated failures in our log. A release tag alone would miss this later activity.
Documentation earns 4/5. On our scale, 1 means no usable starting route, 3 means a route with material gaps, and 5 means those gaps are resolved. Rustlings explains the toolchain, terminal workflow, and file-watcher fallback, but those instructions do not diagnose our failing suite. Support responsiveness and classroom reliability remain unscored because neither was established by this run.
Use the Book for explanation and Rust by Example for quick experiments
The Rust Programming Language is available free online. Choose it when you want the explanation to lead, and bring Rustlings back when you need to work through a compiler complaint yourself. Our existing Book page answers that reading decision. This page concerns the extra local practice loop and the evidence needed to trust its runner.
Rust by Example includes a live code editor. Its README says running examples needs an internet connection, although reading can be offline. Choose that route when browser-based examples remove the immediate toolchain obstacle. For Rustlings, prepare your intended environment and reproduce initialization before the lesson starts. Discovering a runner problem while everyone waits is a poor use of the practice time.