Maps and the zero-value trap — a missing key doesn't panic

Looking up "Nobody", a key that was never set, doesn't panic and doesn't return some Go equivalent of null — it returns int's zero value (the same zero-value concept from the types lesson), which is 0. This is convenient for writing short code without constant existence checks, but it creates a real ambiguity: you can't tell, from that return value alone, whether the key was missing or whether it genuinely exists and its value happens to be 0.

Go's map lookup has a second form that returns an explicit boolean alongside the value, resolving the ambiguity directly:

ok is true if the key actually existed, false if it didn't — this is the idiomatic, reliable way to distinguish "the key is genuinely mapped to the zero value" from "the key was never set at all," and it's a pattern worth reaching for by default anywhere the distinction actually matters.

Returning a zero value instead of forcing an existence check on every single lookup keeps common code much shorter. Counting occurrences, for instance, needs no check at all — a missing key reads as 0, so adding one just works the very first time too:

Go trusts you to use the two-value form only when the distinction between "missing" and "zero" actually matters for your specific logic, rather than forcing every lookup everywhere to be more verbose than it needs to be.

A bug where a counter, a running total, or a cache "just happens" to silently start at 0 for a key that was never actually initialized is a very common Go-specific mistake, precisely because the map lookup doesn't fail loudly the way an out-of-bounds access or a null-pointer dereference would in other languages. Reaching for the value, ok := form whenever "did this key actually exist" is a meaningful question is the concrete habit this lesson is building.