Rust is a compiled, systems-level language, in the same broad family as Go — source code is built into a standalone executable, not interpreted line by line. But the two languages exist for genuinely different reasons, and that difference shapes everything in this course.

Why Rust Exists

Go, JavaScript, Python, Ruby, PHP, and Kotlin all rely on a garbage collector — a background process that automatically frees memory the program no longer needs. This is convenient, but it comes with real costs: runtime overhead, and pause times that are hard to predict exactly when they'll happen. Older systems languages like C and C++ skip the garbage collector entirely, giving the programmer full manual control — but with it, real risk: dangling pointers, buffer overflows, use-after-free bugs that have caused decades of security vulnerabilities.

Rust's entire reason for existing is refusing to accept that trade-off: manual-control-level performance and predictability, without the memory-safety bugs manual control usually invites — enforced not at runtime, but by the compiler itself, before the program ever runs. Chapters 3–4 cover the actual mechanism (ownership and borrowing); this chapter is just naming the goal everything else in this course serves.

Installing Rust: rustup and rustc

rustup is Rust's official installer and toolchain manager — it installs and manages Rust versions, similar in spirit to a version manager, but built and maintained by the Rust team itself as the standard, recommended way to get Rust at all.

rustc is the raw compiler underneath everything — the direct equivalent of what runs behind the scenes when Go's go build compiles a file. In practice, most day-to-day work goes through cargo instead of calling rustc directly.

cargo: Rust's Build Tool & Package Manager

This is the first real toolchain difference from Go. Go's toolchain is deliberately minimal — go run and go build are close to the whole story. cargo bundles far more into one official tool from day one: building, running, dependency management against crates.io (Rust's package registry), and testing — closer in spirit to npm and a bundler combined, except built directly into Rust's own official tooling rather than assembled from separate third-party choices.

Cargo.toml is the direct equivalent of Go's go.mod — but where a go.mod stays minimal, Cargo.toml is the central place dependencies, metadata, and build configuration all live together.

The Smallest Rust Program

fn main() is the entry point — the same role func main() plays in Go; execution always starts here. println! is Rust's equivalent of fmt.Println, but notice the ! — that marks it as a macro, not an ordinary function call. Macros are a genuinely different Rust concept from anything in Go or JavaScript (Course 3's own Macros chapter covers writing them); for now, just recognize that ! after a name means "this is a macro," and println! is the one used constantly throughout this course.

Coding Challenges

Chapter 1 named memory safety as Rust's whole reason for existing. This chapter's first rule is a direct expression of that philosophy: variables are immutable by default — the opposite of what Go, JavaScript, and Python all do.

Immutability by Default

let x = 5; creates an immutable binding — attempting to reassign it is a compile error, not something that fails at runtime or silently succeeds. Mutability has to be opted into explicitly:

This is a deliberate design choice, not an arbitrary restriction: most variables, in practice, are never reassigned after being set — making immutability the default means the compiler can catch an accidental reassignment as a mistake, rather than a program silently doing something the programmer didn't intend.

Scalar Types

Rust's basic scalar types are explicit about size and signedness, unlike Go's simpler int/uint or JavaScript's single Number type:

Compound Types

A tuple groups a fixed number of values of mixed types; an array holds a fixed number of values of the same type. Both have a size fixed at compile time — a dynamically growable list is Vec<T>, covered in Chapter 8.

Type Inference & Explicit Annotations

Rust infers types in most cases — let x = 5; is inferred as i32 without an annotation, the same convenience Go's := provides. An explicit annotation is only needed when the inferred default isn't what's wanted, or when the type genuinely can't be inferred from context alone.

Shadowing

Rust allows re-declaring a variable with the same name using let again — this creates a brand-new binding that shadows the previous one, and can even change its type entirely. This is genuinely different from Go, where redeclaring a name in the same scope with := is usually a compile error unless at least one new variable is being introduced.

The second let input doesn't mutate the original string variable — it creates a separate variable that happens to share the name, and the earlier &str version is no longer accessible from this point in the scope onward.

Coding Challenges

Chapter 1 promised memory safety without a garbage collector. This chapter is where that promise becomes concrete — ownership is Rust's single defining idea, and nearly everything else in this course builds on it.

The Three Ownership Rules

1. Each value has exactly one owner at a time.
2. When the owner goes out of scope, the value is dropped (its memory freed) automatically.
3. Ownership can be transferred (moved), but a value is never implicitly duplicated.

Every example in this chapter is really just these three rules playing out in different situations.

Stack vs. Heap, Briefly

Simple fixed-size types (i32, bool, char, tuples of these) live entirely on the stack — cheap to copy, since copying just means duplicating a few fixed bytes. A String (or Vec, covered in Chapter 8) stores its actual character data on the heap, with only a pointer, length, and capacity sitting on the stack. This distinction is exactly why move semantics matter: moving a String is cheap — it's just copying that small pointer/length/capacity trio, never the underlying heap data itself.

Move Semantics

Coming from Go or JavaScript, let s2 = s1 looks like it should leave both variables usable — either both reference the same underlying string, or the whole value gets copied. Rust does neither: it moves ownership of the heap data from s1 to s2, and s1 becomes invalid from that point on. Using it afterward is a compile error, not a runtime surprise.

Why Not Just Copy Everything?

The alternative — deep-copying on every assignment — would be safe, but expensive, and that cost would be invisible in the code. Rust instead makes moving the default (cheap, just a pointer/length/capacity copy) and requires an explicit .clone() call whenever a real, expensive deep copy is actually wanted — making that cost visible right in the source.

Simple stack-only types (i32, f64, bool, char, and tuples made entirely of these) implement Rust's Copy trait instead — copying them is so cheap that Rust just does it automatically on assignment, and neither variable becomes invalid:

One Owner at a Time & Automatic Cleanup

When a variable goes out of scope — the end of a block or function — Rust automatically calls drop on it, freeing its memory immediately and deterministically. This is the actual mechanism that eliminates the need for a garbage collector: because ownership rules guarantee, at compile time, that exactly one thing is ever responsible for a given piece of data, the compiler always knows the exact moment cleanup should happen — no background process needs to figure it out at runtime.

Ownership and Functions

Passing a value to a function moves it in (unless the type is Copy) — the function becomes the new owner, and the caller's variable becomes invalid after the call, unless the function explicitly hands ownership back by returning the value.

This is genuinely inconvenient if the caller just wanted the function to look at the value without giving it up entirely — which is exactly the problem Chapter 4's borrowing exists to solve.

Coding Challenges

Chapter 3 ended with a real frustration: passing a value to a function moves it, leaving the caller unable to use it afterward. Borrowing is the fix — letting a function use a value without taking ownership of it at all.

References With &

&s1 creates a reference to s1 rather than moving it — calculate_length can read the string, but never owns it. Once the function returns, s1 is exactly as valid as before, solving Chapter 3's function-ownership problem directly.

Mutable References With &mut

&mut lets a function genuinely modify the borrowed value — but this power comes with a strict rule.

The Borrow Checker's Rules

1. At any given time, you can have either any number of immutable references (&) or exactly one mutable reference (&mut) — never both at once.
2. References must always be valid — no reference to something that's already been dropped.

Both rules are enforced entirely at compile time.

Why These Rules Exist

The mutable-XOR-immutable rule prevents a real, classic bug class: something reading data while something else modifies it underneath it. Concretely — if two mutable references to a growing collection existed simultaneously, one holder could trigger a reallocation (the collection outgrowing its current memory and moving elsewhere) while the other still points at the old, now-freed memory location — a genuine dangling-pointer bug that has caused real, exploitable vulnerabilities in C++. Rust's borrow checker makes this class of bug simply not compile, rather than something to carefully avoid at runtime. This is also the foundation of Rust's "fearless concurrency" (Course 2) — the exact same rule that prevents this single-threaded aliasing bug also prevents data races between threads.

Dangling References

In C or C++, this same pattern compiles and produces a genuine dangling pointer — undefined behavior waiting to happen at runtime, possibly much later and far from where the actual mistake was made. In Rust, it's simply a compile error: the borrow checker sees that s is dropped at the end of the function, and refuses to let a reference to it escape.

Rust's Alternative to Go's GC

The full arc from Chapter 1 is now complete. Go's garbage collector scans memory at runtime to find and free data nothing references anymore — genuinely useful, but with real runtime overhead and pause times that are hard to predict exactly when they'll land. Rust's borrow checker instead analyzes ownership and borrowing entirely at compile time — by the time a Rust program actually runs, every memory-safety guarantee has already been proven, with zero runtime cost for that safety, no background process ever running, and the deterministic drop timing Chapter 3 introduced.

Coding Challenges

With ownership and borrowing established, this chapter combines fields into custom types and gives them behavior — territory Go's own go2-1 (Structs, Methods, Pointers) already covered, making this a natural place for direct side-by-side comparison.

Defining a Struct

A named collection of typed fields, accessed with dot notation — the same basic shape as a Go struct definition.

impl Blocks

Rust keeps a struct's data definition and its behavior definition separate — fields live in struct, methods live in a separate impl ("implementation") block. This is actually a genuine similarity to Go, not a contrast: Go also separates data (the struct) from behavior (a function with a receiver), unlike Java or Kotlin, which bundle both inside one class body.

Methods (&self)

A method's first parameter is &self — a borrowed reference to the instance (Chapter 4's & in action), giving read access to its fields without taking ownership. Called with dot syntax: rect.area().

Associated Functions (No self)

A function inside an impl block without self is an associated function — not a method, and it can't be called on an instance with dot syntax. It's called via Struct::function_name() instead. The most common use is a constructor:

This is exactly the same :: syntax that's already appeared constantly since Chapter 1 — String::from("hello") is nothing more than a call to an associated function named from defined in String's own impl block. Go has no real language equivalent: a Go "constructor" is just an ordinary function following a naming convention (NewRectangle(width, height float64) Rectangle) — Rust's :: namespacing is a genuine language feature tied directly to the type itself, not a convention.

Coding Challenges

Chapter 5 covered structs. This chapter covers Rust's other major custom type — and it's genuinely more powerful than what Go calls an "enum," which is really just a sequence of typed integer constants built with iota.

Enums That Carry Data

A Rust enum variant can hold its own associated data — and different variants can hold entirely different shapes of data. Go's iota-based constants are just named integers; there's no way to attach data to one at all.

V4 and V6 aren't just labels — each is effectively its own little data structure, holding whatever shape of data actually fits that variant.

The match Expression

Rust's match is a switch-like construct, but stricter and more useful: it's an expression (it produces a value), and it must be exhaustive — every possible variant needs a matching arm, or an explicit _ catch-all. Missing a case is a compile error, not silent fall-through the way an incomplete switch in Go or JavaScript can behave.

Each arm destructures the variant's data directly — IpAddr::V4(a, b, c, d) pulls all four numbers out in one line, ready to use immediately.

Option<T>: No Null At All

Rust has no null or nil value at all — the concept doesn't exist in the language. Anything that might be absent is instead wrapped in the built-in Option<T> enum:

You cannot accidentally treat a None as if it were a real value — the compiler forces every Option<T> to be handled (via match, and later if let/unwrap) before the real value inside a Some can be used at all.

Coding Challenges

Chapter 6's Option<T> handled absence. This chapter handles the other "might not work" case: an operation that can fail with a reason why — and, genuinely more than most mainstream languages, Rust's approach here has real common ground with Go's own explicit error handling.

Result<T, E>

Same basic shape as Option, but the failure case carries a value (E) explaining what went wrong, not just an absence.

Rust making errors part of the function's return type, rather than an exception, is genuinely the same core philosophy Go's own (value, error) convention already uses — a real similarity, not just a contrast, distinguishing both languages from JavaScript/Python's try/catch exception model.

panic! vs. Recoverable Errors

panic! immediately stops the program — reserved for genuinely unrecoverable situations: a real bug, a broken invariant, something that should structurally never happen. Result is for expected, recoverable failure conditions: a missing file, invalid user input, a failed network call. Rust's convention is clear about which to reach for: Result for anything a caller might reasonably want to handle; panic! only for "this should never happen."

The ? Operator

Go's error handling requires an explicit check after every single call that can fail: if err != nil { return err }. Rust's ? operator does the exact same propagation in one character: if the expression is Err, it returns that Err immediately from the current function; if it's Ok, it unwraps the value and execution continues.

unwrap() and expect()

.unwrap() extracts the Ok/Some value directly — or panics if it's actually Err/None. .expect("message") does the same, with a custom panic message. Both are genuinely useful for quick prototypes or cases that are truly certain to succeed — but reaching for them on an operation that could realistically fail in production turns a recoverable situation into a full program crash.

Coding Challenges

Chapter 2's arrays were fixed-size. This final chapter of Course 1 covers Rust's growable collections — and the iterator adapters that process them in a style that will feel immediately familiar coming from JavaScript.

Vec<T>: A Growable Array

Vec<T> can grow and shrink at runtime, backed by a heap allocation — genuinely similar to Go's own slice type, which is Go's own answer to "an array that can grow." This is a real similarity worth noting, not just another contrast.

HashMap<K, V>: Key-Value Storage

get returns Option<&V> — Chapter 6's Option making a direct return appearance. Go's built-in map[string]int is more tightly woven into the language's own syntax, and its lookup returns a (value, ok bool) pair — both languages are explicit about "this key might not exist," just expressed through different mechanisms (Go's two-value return vs. Rust's Option).

Iterator Adapters: map, filter, collect

Rust's iterator methods will feel immediately familiar coming from JavaScript's own array methods — the naming and behavior are genuinely close.

.iter() creates an iterator of references (borrowing, Chapter 4) without consuming numbers. .filter() and .map() are lazy — nothing runs until .collect() actually consumes the chain and builds a new Vec.

Ownership Implications of Iterating

Rust has three distinct ways to iterate, and choosing the wrong one is a genuinely common point of confusion:

Neither Go nor JavaScript has this distinction at all — their iteration never "consumes" the underlying collection the way into_iter() does.

Coding Challenges