Ultimate Rust Crash Course: eleven exercises, a frozen branch for old students, and half the links pointing at the wrong branch

Eleven exercises, ordered as a dependency graph rather than a syllabus

The exercise list is the whole curriculum, and reading it in order tells you what the course considers foundational.

The first is variables and scope, and it is described as being just a readme file with no code at all, which is a deliberate choice rather than an omission. Learning a language's scope rules is a reading and prediction exercise, not a writing one, and putting it first as prose means a student arrives at the second exercise already thinking about lifetimes without having been asked to.

Then functions, modules, simple types, control flow, and strings. Strings come sixth, before ownership, and that ordering is the one worth noting: string handling is where a borrow checker first becomes a real obstacle rather than a technicality, and doing it before the ownership lesson means the ownership material has a concrete example already in the student's head.

Ownership and references is seventh, and it is the exercise the whole course is built around. Structs, traits, collections and enums follow. That last ordering is also deliberate: traits before collections, and collections before enums, so that by the time a student meets an enum they have already written generic dispatch and have a collection to put the variants in.

Each exercise is its own project under a single directory, each with its own manifest, and the readme is emphatic that you open one at a time. The stated reason is concrete: an editor that sees the whole repository finds several Rust projects at once and complains. That is a real and specific piece of advice, and it is the kind of thing a companion repository only learns to say by having people hit it.

The delivery mechanism is equally specific. The instructions are numbered comments inside the main source file, not a separate document, so a student reading the code and reading the task are reading the same screen. That is a good decision for a language whose errors are about the code itself, and it means the exercise cannot drift out of sync with the file it describes the way a separate worksheet can.

Half the exercise links point at a branch that is no longer the default

Here is the bug, and it is worth describing precisely because it is the kind of thing that costs a reader fifteen minutes and gets blamed on their own setup.

The default branch for this repository is named main. The exercise list contains eleven links. Seven of them, covering the first seven exercises, are built against a branch named master. The remaining four, covering the last four exercises, are built against main. The companion page linked in the development environment checklist is also built against master.

So following the readme from top to bottom, a reader clicks the first exercise link and lands on a branch that is not the one the repository defaults to. Depending on how the host handles a renamed default branch, that either redirects silently, which works, or it does not, which produces a not found page. And if it redirects, the reader is silently moved to whatever that branch contains, which may not be the version the surrounding instructions were written against.

There is a second branch in play as well, and it is the more interesting one. A prominent note at the very top of the readme tells existing students of a previous commercial edition to use a separately maintained branch instead, because the main branch has been updated since the author's courses moved to a different training platform. So the repository carries at least three branch names: the current default, the name the older links were written against, and a frozen branch for people who paid for a specific version of the material.

Freezing a branch for existing students is the right call and more publishers should do it. The failure is in the links, not the policy. A readme that mixes two branch names in one list was edited in two sittings and never swept, and the cost falls on exactly the readers the note at the top is trying to protect.

The practical workaround is trivial and worth stating: ignore the links entirely and navigate the exercise directories from your own clone. The directory names are alphabetical and the letters match the exercise letters, so the list order and the on-disk order agree.

The editor instruction is the most load-bearing line in the readme

The development environment section is a checklist of five items, and one of them carries an instruction strong enough to warrant repeating.

The line tells editor users on the market with the largest Rust user base to install one specific extension, and, if they have a different Rust extension already installed, to uninstall it. The emphasis in the original is not subtle.

This is the correct instruction and it is worth understanding why, because it generalises beyond Rust. A language that has been through a change of official tooling keeps the old tooling in the extension marketplace for years, because a large installed base depends on it. A new Rust project in 2026 will have both extensions offering language support, and the two will disagree about what your code means. The most common first-day symptom of a new Rust student is a red squiggle that they cannot explain, and it is very often caused by having two competing language servers rather than by anything wrong with their code.

The checklist's other items are less surprising but no less useful. The second item is to pick one place to find answers and either introduce yourself or find the answer to one question there, which is advice about the shape of a learning process rather than about a tool. The third is a do-anything smoke test: create a project, run it, edit the main source file, run it again. That five-line sequence is the smallest possible confirmation that the toolchain works, and having it written down saves a beginner from interpreting a toolchain problem as a learning problem.

The first item is the tooling decision and the last is a pointer to a companion page describing the tools and books in more detail. The readme also asks readers to report problems directly to the author, giving an address and a link to open a discussion. For a paid course companion that is a reasonable thing to offer, and the fact that the author developed the material on one operating system and says so, while stating that everything ought to work on the other two, is a candid thing to write about the limits of your own testing.

A pinned compiler version dates the course more precisely than any changelog would

The installation section does two things that are worth separating, because one is advice and the other is a time stamp.

The advice is to get the toolchain from the official language site rather than from a system package manager, with the reason given plainly: a package manager will probably give you a version that is really old. The second part is that if you already have an old version, the toolchain's own updater is the way to move forward. Both are correct and both are the kind of thing that saves a beginner an afternoon, because a Linux user following a distribution's package instructions will get a compiler that predates several editions of the language and will then spend hours on syntax errors that are version problems.

The time stamp is the sample output. The readme shows the compiler version and the build tool version, both at a specific release:

rustc --version
rustc 1.89.0 (29483883e 2025-08-04)
cargo --version
cargo 1.89.0 (c24e10642 2025-06-23)

The compiler shown is from August 2025 and the build tool from June 2025. It is presented as representative rather than required, with a note that newer versions are fine.

That is a well-judged way to present it, and it has a consequence that is easy to miss. If a student installs the latest stable compiler rather than the one shown, they are on a newer edition of the language than the course was written against, and editions of Rust are not additive. Deprecated syntax still compiles, sometimes with a warning, and sometimes the edition mechanism changes the meaning of a construct the course taught. For a fundamentals course the risk is low, but the general point holds: a pinned toolchain in a companion repository is a compatibility promise, and this one is roughly a year old.

The second edition of the material lives in a separate repository, and the readme points at it directly for anyone who liked the first one. Two repositories, one per edition, each with its own exercise set, is a clean way to handle the problem of a course that has to keep working for people who bought a specific version of it. It is also the pattern that produced the frozen branch described earlier, which suggests the author has been improvising solutions to the same problem for a while.

What a course companion repository is actually for

It is worth being explicit about what this repository is, because the name invites the wrong expectation. There is no library here, no command to install, and no service to run. The top-level listing is an editor configuration file, a gitignore, an editor settings directory, one companion page, the licence, the readme, an examples directory containing a single hello project, and the exercise directory.

The single example project is the tell. It is there so that the toolchain smoke test in the checklist has something to point at and so that a student who wants to see a working project before touching the exercises has one place to look.

So the repository is a worksheet. Its entire value is in the eleven projects, the comments inside them, and the discipline of the ordering. Everything else is scaffolding: the environment checklist exists so that a student does not fail at exercise two for reasons unrelated to exercise two, and the companion page exists so that the readme does not have to be a document about learning.

That has an honest implication for anyone evaluating it. A worksheet cannot be tested, so there is no continuous integration, no test suite and no release history, and the absence of tags is not an oversight. It also cannot be maintained in the way software is, because its correctness depends on a compiler version and on a course that now lives on a commercial platform. The readme's own solution to that, a frozen branch for existing students, is the right shape of answer, and the broken links are the price of applying it incrementally rather than in one pass.

What a student should take from all of this is the ordering and the comments, and leave the rest. The ordering is the author's judgement about how the language should be entered, and it is a good one. The comments are unusually well suited to the task, because they put the instruction and the code under the same cursor. The links are the weakest part of an otherwise careful document, and they are the part most likely to be the first thing that breaks.

Editorial conclusion

The Ultimate Rust Crash Course exercises are worth working through if you are new to Rust and want a guided path through the ownership model, because the ordering is deliberate and the instructions sit next to the code rather than in a separate document. They are less useful as a reference once you have written your first non-trivial program, since the material is introductory by design. Before you start, follow the readme's instruction to install the toolchain from the official site rather than from a system package manager, open each exercise directory individually rather than the repository root, and install the language server the readme names while removing the other Rust extension, because having both is a common cause of a first-day confusion. Ignore the exercise links and navigate the directories yourself, since some of them point at a branch that is no longer the default.

Frequently asked questions

Official sources

1. CleanCut/ultimate_rust_crash_course on GitHub
2. Issues
3. License: MIT
4. README