Six Go Gotchas the Compiler Won't Catch

Go’s compiler catches a lot. It does not catch these six. Each one compiles fine, passes a quick glance in review, and produces the wrong answer only when you actually run it.

Loop Variables and Goroutines

The classic version of this bug: every goroutine in the loop reads the same shared variable, so they all print the last item.

1
for _, item := range items {
2
    go func() {
3
        fmt.Println(item)
4
    }()
5
}

Go 1.22 changed the semantics so each iteration gets its own item, and this now prints what you’d expect. But the fix is gated by the go directive in go.mod. If that file still says go 1.20, you get the old per-loop variable even on a brand new toolchain. I got bitten by this after upgrading Go locally but not bumping go.mod — the bug was “fixed” on my machine and not fixed in CI.

If you’re not sure which behavior you’re getting, pass the loop variable in explicitly. It works under both semantics and costs nothing:

1
for _, item := range items {
2
    go func(item string) {
3
        fmt.Println(item)
4
    }(item)
5
}

A Nil Pointer Is Not a Nil Interface

1
type MyError struct{}
2

3
func (e *MyError) Error() string { return "boom" }
4

5
func doSomething() error {
6
    var err *MyError = nil
7
    return err
8
}
9

10
func main() {
11
    err := doSomething()
12
    fmt.Println(err == nil) // false
13
}

err here is an interface value with a concrete type (*MyError) and a nil pointer inside it. The interface itself is not nil, because it knows its type. This is why “return a typed nil as an error” is a footgun and not just a style nitpick — the caller’s if err != nil check passes even though nothing went wrong. The fix is boring: return the untyped nil literal, not a nil variable of a concrete type.

Append Can Silently Overwrite a Shared Array

1
a := []int{1, 2, 3}
2
b := a[:2]
3
b = append(b, 99)
4
fmt.Println(a) // [1 2 99]

b is a slice over the same backing array as a, with capacity 3. Appending one element fits inside that capacity, so Go reuses the array instead of allocating a new one — and a[2] gets clobbered. Nothing here panics or warns you. It only shows up as data that changed somewhere you never touched it. If you’re handing a sub-slice to something that might grow it, copy it first or reslice with a capacity limit (a[:2:2]) to force a reallocation on append.

Shadowed err Swallows the Result You Wanted

1
data, err := fetch()
2
if err != nil {
3
    return err
4
}
5

6
if data, err := transform(data); err != nil {
7
    return err
8
}
9

10
return process(data) // still the ORIGINAL data, transform's output is gone

:= inside the if only needs one new variable to be legal, and being in a new block scope means both data and err count as new there — even though identically named variables exist outside. The transformed value never escapes the if. This one is nasty specifically because it compiles silently and the success path looks correct; it only breaks once transform actually changes something.

defer Inside a Loop Doesn’t Run Per Iteration

1
func processFiles(paths []string) error {
2
    for _, p := range paths {
3
        f, err := os.Open(p)
4
        if err != nil {
5
            return err
6
        }
7
        defer f.Close()
8
        // process f
9
    }
10
    return nil
11
}

defer runs when the enclosing function returns, not when the loop iteration ends. Loop over a few hundred files and you’ll hold a few hundred open file descriptors until processFiles itself returns, which is how I once got a “too many open files” error from a function that looked completely reasonable. Pull the per-file work into its own function (or an inline closure) so the defer has a smaller scope to close over.

range Copies the Value

1
type Counter struct{ N int }
2

3
counters := []Counter{{N: 1}, {N: 2}}
4
for _, c := range counters {
5
    c.N++
6
}
7
fmt.Println(counters) // unchanged: [{1} {2}]

c is a copy of each element, so mutating it does nothing to the slice. This one is usually caught fast because the output is obviously wrong, but it’s still a common first reaction of “wait, why didn’t that update?” Index into the slice instead if you need to mutate in place:

1
for i := range counters {
2
    counters[i].N++
3
}

None of these are exotic. They’re all things the spec explains clearly if you go looking, which is exactly the problem — you only go looking after they’ve already cost you an hour.