Challenge 3: Zero Runtime Cost, Explained — Possible Solution
====================================================================

Go's garbage collector does its safety-relevant work WHILE THE PROGRAM
IS RUNNING — it periodically scans memory at runtime, determines which
allocations are still reachable, and frees the ones that aren't. This
is genuinely necessary work, but it happens continuously, alongside
the program's own logic, consuming CPU time and introducing pause
times that are difficult to predict exactly when they'll occur — the
safety mechanism has an ongoing, real runtime cost for as long as the
program executes.

Rust's borrow checker does its safety-relevant work ENTIRELY AT
COMPILE TIME, before the program ever runs at all. It analyzes
ownership (Chapter 3) and borrowing (this chapter) statically,
proving — as part of compilation itself — that no dangling references,
no simultaneous mutable-and-immutable access, and no ambiguous
ownership exist anywhere in the code. Once compilation succeeds, those
guarantees are already established; there is no ongoing process
checking them again while the program executes, because there's
nothing left to check — the compiler already proved it.

This is the precise sense in which Rust's approach has "zero runtime
cost": the SAFETY CHECK itself happens once, at compile time, and
costs nothing during execution — contrasted with Go's GC, whose
safety-relevant work (finding and freeing unreachable memory) is, by
necessity, an ongoing runtime activity for as long as the program is
alive.