Challenge 3: Explaining Rust's Trade-off — Possible Solution
====================================================================

A garbage-collected language (Go, JavaScript, Python, Ruby, PHP,
Kotlin) trades away some performance predictability for safety and
convenience: memory is freed automatically, but a background garbage
collector introduces runtime overhead and pause times that are hard to
predict exactly when they'll occur — the programmer doesn't manage
memory directly, but also doesn't get full control over when cleanup
happens.

C and C++ trade the opposite way: the programmer gets full manual
control over memory (allocating and freeing it explicitly), which
enables maximum performance and predictability — but with real,
well-documented risk: dangling pointers, buffer overflows, use-after-
free bugs. Decades of serious security vulnerabilities trace back
directly to this manual-memory-management risk.

Rust's trade-off is genuinely different from BOTH of these: it keeps
C/C++'s lack of a garbage collector (no runtime overhead, predictable
performance) while eliminating the memory-safety bugs manual
management usually introduces — not by adding a runtime safety net
(which would reintroduce overhead), but by having the COMPILER itself
enforce memory-safety rules before the program is even allowed to
run. This is why Rust's pitch isn't "as safe as a GC language" or "as
fast as C" in isolation — it's specifically both at once, achieved by
moving the safety guarantee to compile time rather than runtime.

THE TWO CHAPTERS THAT DELIVER ON THIS: Chapter 3 (Ownership) and
Chapter 4 (Borrowing & References) — these introduce the actual
mechanism (move semantics, the borrow checker) that lets the compiler
verify memory safety without any garbage collector ever running.