Why you will feel stupid, and why that is the plan

You have six years of experience and you have picked up languages before. Go took you a couple of weekends. TypeScript was barely a speed bump. So the honest question at the start of a Rust course is: why would this one be different, and why is this site built to slow you down?

Here is the short answer. Every language you have learned so far shared one model with the languages you already knew: a variable is a name that refers to a value, and something else takes care of memory. JavaScript, TypeScript, Java and Go all agree on that. Learning them was mostly learning new syntax and new libraries on top of a model you already had.

Rust disagrees with all four of them, at the level of what a variable is. You are not adding to your model. You are replacing part of it. That is a different kind of work, and the research on it is unambiguous: it is slower, it feels worse, and the usual study methods fail at it in a specific way.

The trap: your existing model is fast, confident, and wrong

Let us establish the loop immediately. This is the pattern for every lesson.

fn main() {
    let s = String::from("hello");
    let t = s;
    println!("{s}");
}

error[E0382]: borrow of moved value: `s`
 --> src/main.rs:4:15
  |
2 |     let s = String::from("hello");
  |         - move occurs because `s` has type `String`,
  |           which does not implement the `Copy` trait
3 |     let t = s;
  |             - value moved here
4 |     println!("{s}");
  |               ^^^ value borrowed here after move

That absence of doubt is the whole problem. A wrong model that produces doubt gets checked. A wrong model that feels obvious does not — you read straight past it, and it stays.

Why reading The Book is not enough

The Rust Book is genuinely excellent. That is precisely why it is dangerous for someone in your position.

Well-written explanations produce fluency — the reading goes smoothly, each sentence follows from the last, and you finish the chapter with a warm sense of having understood it. That feeling is a real psychological state and it is almost uncorrelated with whether you can use the material later. The literature calls this the illusion of fluency or the illusion of knowing, and it is one of the most replicated findings in the study of learning.

The mechanism is simple. Clear prose removes difficulty. But a specific kind of difficulty is what causes learning. Remove it and you get the comfort without the effect.

Robert Bjork’s term for the useful kind is desirable difficulties: practice conditions that make performance worse now and learning better later. The four with the strongest evidence are:

• Retrieval — pulling an answer out of memory, not recognising it on a page.
• Spacing — meeting the same idea again after you have partly forgotten it.
• Interleaving — mixing topics so you must first work out which idea applies.
• Generation — producing an answer before being told one, even a wrong one.

Every one of these makes a course feel harder and score worse on “did you enjoy this module?” surveys. That is roughly why you have not met them in a programming course.

Rust has the best learning oracle of any language, and courses waste it

Here is something genuinely underused.

Predict-Observe-Explain is a technique from science education. You commit to a prediction, you observe what actually happens, and then you explain the gap. It works because the commitment creates a stake, and the mismatch creates surprise, and surprise is what makes a confident wrong model finally move.

Its usual weakness is the “observe” step. In a physics classroom you need apparatus, setup, and a teacher to adjudicate what the result meant.

Rust hands you a perfect oracle for free. rustc is instant, authoritative, and completely unambiguous about whether you were right — and its error messages are frequently better explanations than the textbook’s. A physics teacher would give a great deal for an instrument this good. Rust courses use it as a build tool.

So this course uses the compiler the way a science course uses an experiment. Which brings us to the rules.

The five rules

1. Never read past a Predict box without typing something. Not thinking it — typing it. A thought like “hmm, probably an error?” is too vague to be wrong, and something that cannot be wrong cannot surprise you. It takes ten seconds and it is the highest-value thing on this site.

2. Rate your confidence honestly, including when it is high. The site records your confidence and later shows you your accuracy at each level. For an experienced engineer learning a new language, overconfidence — not inability — is the main obstacle, and it is invisible without measurement. You already have rustc 1.96 installed; the Calibration page is where you find out how much your intuition can currently be trusted.

3. Check against a compiler, not against your feeling. Every self-contained snippet on this site has a Run button that compiles it on the real Rust Playground and shows you rustc’s actual output — including the full error, which is frequently a better explanation than the surrounding prose. Use it, especially when you are sure. Better still, keep a scratch crate open:

cargo new scratch && cd scratch

4. Come back on days you did not plan to. The Review queue uses expanding intervals and mixes topics on purpose. When a question about lifetimes arrives next to one about Send, you have to work out which idea applies before you can answer — and that sorting step is the skill that survives contact with real code. Grouping by topic lets you skip it.

5. Stop when you can explain it out loud, not when you are bored. This is the tech-lead test and it is the actual goal of the course. If you cannot say it in a sentence without looking, you do not have it yet.

About the English

A note, since English is not your first language and this material is dense.

Rust’s community vocabulary is unusually precise, and much of it is metaphorical: values are “moved”, references are “borrowed”, a trait is “implemented for” a type, a lifetime “outlives” another. These are not casual descriptions. Each is a technical term with an exact meaning, and using them loosely is how a discussion goes wrong.

So this course does two things about language. Terms are defined at first use and never assumed. And the Glossary gives every important term a plain definition plus a real sentence showing how Rust programmers actually use it — because knowing what dyn-compatible means and knowing how to say “that trait isn’t dyn-compatible” in a design review are different skills, and you need the second one.

What comes next

0.2 gives you the frame that organises everything else — the claim that Rust has three machines, and that most confusion is using the wrong one. It also contains a ten-question pretest.

You will do badly on that pretest. That is intended, and it is not a figure of speech: being tested on material you have not learned yet measurably improves how well you learn it afterwards, even for the questions you get wrong. It is called the pretesting effect. Do not look anything up.