[inlined]

This. Nil is the one case where you can seriously screw your self up in Go because it’s an untyped literal that gets typed on assignment. Interfaces are fat pointers and a “true” nil pointer is nil interface, nil implementation. If your function is going to return a known subtype and you store that nil in a temporary you now return a known interface and nil implementation. Then your == nil check on the interface pointer will fail.

I royally screwed up a deploy once because my functions were returning nil error implementations that were != nil and triggered failure paths.

[weberc2]

I agree that nil is error prone, but I don’t think interfaces add any additional confusion so long as you think of them as a reference type and reason accordingly. Also, I think you’re mistaken about “true nil”. A “true nil” only requires the interface to be nil. The value doesn’t matter as there necessarily is no value (moreover interfaces can have values which are value-types that cannot be nil!).