Challenge 3: When Each Language Catches the Mistake — Possible Solution
====================================================================

In Go, a value that might be absent is typically represented as a nil
pointer or a nil interface — but nil is still, as far as the type
system is concerned, a perfectly valid value of that same pointer/
interface type. Nothing about the type signature distinguishes "a real
pointer" from "a nil pointer" — the compiler happily allows code to
dereference it without any special handling. The mistake (dereferencing
a nil pointer) is only caught at RUNTIME, when the program actually
tries to use the nil value and panics — potentially long after, and far
away from, wherever the nil value actually originated.

In Rust, an absent value is represented as Option<T>'s None variant —
but crucially, Option<T> is a COMPLETELY DIFFERENT TYPE from T itself.
A function returning Option<i32> does not return an i32 at all; it
returns an Option<i32>, and there is no way to extract the underlying
i32 without going through some form of explicit handling (match,
if let, unwrap, etc.) that the compiler requires. This means the
mistake of treating an absent value as if it were present is caught at
COMPILE TIME — the code simply won't compile until every Option is
properly handled — rather than being deferred to a runtime crash.

THE CORE DIFFERENCE: Go's nil is a valid value OF THE SAME TYPE as a
real value, so misuse is a runtime error; Rust's None lives inside a
DIFFERENT TYPE (Option<T>) than the real value (T), so misuse is
structurally impossible to compile in the first place.