To be fair, we don't know if `Baz` is a pointer or value receiver in the parent example. So it could: https://play.golang.org/p/fYO8jBbVQ5

That's true, but it's pretty uncommon for a function to receive a value, and if so you either have a good reason for it or you're doing something wrong.

You created a playground that intentionally avoids the nil ptr dereference.

https://play.golang.org/p/Cu4sE829ZZ

You can actually create meaningful implementations of methods on nil pointers.

    if b == nil {
        fmt.Println(":)")
    } else {
        fmt.Println(b.emote)
    }

In this case, that's useless, but that's an artifact of the chosen example. I use it every so often in places where it happens to have meaning.

Go often treats nil as a legal value, which means that some of the things you might expect to crash don't, and when used idiomatically can sometimes make for shorter code. For instance, the "length" call on slices will happily take a nil and return 0, you can "append" to a nil slice and get a slice back, etc. Ultimately it's still a language with a null in it, though. There's no non-nil pointer type.