Gotchas

Few bugs in Go are as disorienting as this one: you return nil from a function, check the result against nil, and the check fails. No type assertion panic, no runtime error — just a quiet wrong answer that sends you down a debugging rabbit hole.

A goroutine leak is one of the most insidious bugs in Go. Unlike a memory leak in C, nothing crashes. No panic, no OOM killer. Your service just slowly grows in memory and CPU usage over hours or days until it falls over — or someone notices the goroutine count in a dashboard.

defer is one of Go’s most useful features and one of its most misunderstood. The documentation is precise: a deferred call runs when the surrounding function returns — not when the surrounding block or loop iteration ends. That single sentence is responsible for resource leaks, silent data corruption through named returns, and unnecessary performance overhead that persists until you know to look for it.

Slices are the bread and butter of Go programming. Most developers use them daily without thinking twice — and that comfort is exactly where subtle, load-dependent bugs come from. This article pulls back the curtain on how slices are represented in memory and explains the class of bug that emerges when two slices quietly share the same underlying array.