Runtime

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.

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.

In the Go runtime, the scheduler is the engine that manages how thousands of goroutines are multiplexed onto a limited number of operating system threads. To ensure system responsiveness and prevent “resource hogging,” Go employs a mechanism called preemption.