Right, so you’ve got your interfaces working, you’re feeling good about your code, and then BAM. Your program does nothing. Or worse, it panics. You check your logic a hundred times and it’s flawless. The culprit? It’s probably this little nightmare: the difference between a nil interface and an interface holding a nil pointer. It’s the kind of subtle bug that makes you want to have a stern word with the language designers, but I promise there’s a method to this madness.

The key is to understand that an interface value isn’t just a magic blob. It’s a two-part structure under the hood: a type and a value. The value is the concrete thing you shoved into the interface, and the type is, well, its type.

When you have a plain nil, you have… nothing. Zero. Zilch. An interface variable that has never been assigned anything is in this state. Its type is nil and its value is nil. This is a nil interface value.

But here’s the kicker: if you assign a nil pointer to an interface, you’re performing an action. You’re saying, “Hey, interface, hold this.” And the interface does what it’s told. It now has a very specific type (*MyStruct) and a value (nil). This is an interface value holding a nil pointer.

Why does this distinction matter? Because when you go to use that interface (e.g., call a method on it), Go only panics if the interface value itself is nil. If the interface holds a nil pointer, it happily resolves the type and tries to call the method… on a nil receiver. Let’s see this in action.

The Code That Will Confuse You at 2 AM

type Cat interface {
    Meow()
}

type Tabby struct {}
func (t *Tabby) Meow() { fmt.Println("Meow!") }

func GetACat() Cat {
    var myTabby *Tabby = nil // We have a nil pointer
    return myTabby            // We return it as a Cat interface
}

func main() {
    var c Cat
    fmt.Println("c is nil:", c == nil) // This will print true. Good.

    c = GetACat()
    fmt.Println("c is nil:", c == nil) // This will print FALSE. Wait, what?
    
    if c != nil {
        c.Meow() // This will... run? And panic inside the method.
    }
}

Running this will likely output:

c is nil: true
c is nil: false
panic: runtime error: invalid memory address or nil pointer dereference

See the problem? Our if c != nil check passed because c itself was not a nil interface. It was an interface value that knew it was of type *Tabby and just happened to be holding a nil. So the code blithely tries to call Meow() on a nil receiver, and inside the method, when it tries to access t.SomeField, it panics. This is the bug in its natural habitat.

Why on Earth Would This Be Useful?

You’re right, it feels like a gotcha. But it exists because interfaces are designed to be… ignorant. They don’t know or care what the underlying value is; they just know how to call methods on it. The ability to hold a nil pointer of a specific type is actually powerful once you get past the initial frustration.

It allows you to have a valid, non-nil interface variable that you can safely pass around and call methods on if those methods are designed to handle a nil receiver. This is the crucial part. Look at the standard library’s *http.Request. Its Context() method handles a nil receiver. We can write our Meow method to do the same.

func (t *Tabby) Meow() {
    if t == nil {
        fmt.Println("<silence>") // Handle the nil case gracefully
        return
    }
    fmt.Println("Meow!")
}

func main() {
    c := GetACat() // Still returns an interface holding a nil *Tabby
    if c != nil {  // This is still true
        c.Meow()   // This now safely prints "<silence>"
    }
}

Now our code doesn’t panic. The interface machinery worked exactly as intended. The bug wasn’t in Go’s handling of interfaces; it was in our method implementation for not accounting for a nil receiver.

The Golden Rule: Always Check Your Receiver

This leads us to the best practice that will save you countless hours of debugging:

If it’s even remotely possible for a pointer method to be called via an interface that might hold a nil pointer, you must check the receiver inside the method.

It’s a small piece of defensive programming that makes your code incredibly robust. The GetACat function might be a factory function that returns nil on error. The calling code might receive a valid interface and not know the concrete value is nil. Your method is the last line of defense.

So the next time your if myInterface != nil check passes and your code still blows up, don’t blame Go. Take a deep breath, remember the two-part structure, and go add that nil check in your method. Your brilliant friend told you so.