0.5The compiler, Cargo, and crates

Last updated June 11, 2026

In the previous lesson (0.4), we walked through steps 1–3 of development: define, design, write. Now for steps 4 through 7 (compile, build, test, debug) and the tools Rust hands you for them.

The Rust compiler

The Rust compiler is a program called rustc, and when you point it at your source code it does two jobs, in order.

First, it checks your program. Some of the checks are grammar (is this even valid Rust?), but most of them are deeper: are you using values in ways their types allow? Could this variable be read before it has a value? Could this memory be used after it's gone? Rust's compiler checks far more than most languages' do. That's the deal we described in lesson 0.3, where errors get caught at compile time instead of while the program runs. If any check fails, you get an error message, and no program is produced.

Second, if your code passes, rustc translates it into machine code and, together with a helper program called a linker (it stitches in prewritten code your program relies on), produces an executable: the ready-to-run file from lesson 0.2. Translating-plus-stitching as a whole is called building. The result runs on its own; whoever you give it to doesn't need Rust installed, and never sees your source code.

Cargo

Here's the thing, though: you will almost never run rustc yourself. Rust ships with a tool called Cargo, and Cargo is the tool you'll actually live in. It does two jobs that other languages usually split across many tools.

It's the build tool: cargo new creates a fresh project with the right structure, cargo build compiles it (invoking rustc for you, with the right settings), cargo run builds and then runs it, cargo test runs your tests. One consistent interface, from hello-world to a million-line codebase.

It's also the package manager. That's the half that needs some explaining.

Crates

Nobody builds software entirely from scratch. If your program needs to talk to a web server, generate a random number, or decode a JPEG, the sane move is to use code someone has already written, polished, and tested. A unit of shareable, compilable Rust code is called a crate. Your own program is a crate too (you'll make your first one in lesson 0.8); crates are the bricks Rust code comes in.

The community's public crates live at crates.io, a free registry of more than 150,000 of them. When your program needs one, you declare the dependency in a project file, and Cargo handles the rest: downloading it, downloading whatever it depends on, and compiling everything into your build in the right order. Managing dependencies is the "package manager" half of Cargo's job, and you'll do it for real in lesson 7.9, adding random numbers to your first game.

One crate is special enough to be invisible: the standard library (called std), which ships with Rust itself. It covers the everyday needs (printing to the screen, reading input, text, collections, files) and every program gets it without asking. When code in this course seems to use things we never declared as dependencies, std is where they're coming from.

Testing and debugging

That leaves steps 6 and 7. Testing is checking that your program does what you meant. Rust, true to form, ships the machinery in the box: you can write tests next to your code and run them all with cargo test. Testing gets a full chapter (chapter 14) once you have code worth testing. Debugging is what happens when testing finds a problem: locating the cause and fixing it. That's chapter 3, and it comes early on purpose, because you'll be debugging from your first week, so you may as well be good at it.

That's the whole tour: rustc builds, Cargo drives, crates supply the parts, tests catch the breakage, and you fix what they catch. Enough theory. In the next lesson, we install all of it.