My experience is the same. Go mitigates pointer problems very well by having zero values and explicitly separating error returns.<p>If anyone complains about having nil in Go, I usually assume they&#x27;re either forced to work a really bad codebase or lack experience in Go.<p>I&#x27;ve worked on a Go codebase for ~2 years, and I&#x27;m pretty sure the only nil pointer dereference I&#x27;ve seen was due to a concurrency bug, where an object cache (implemented as an array, not sync.Pool) was not locked properly.<p>The problem with having nil is when you expect a value to be  either a valid pointer or nil to indicate an error, and you forget to check for an error. In Go, in my experience, explicit error checking and multiple return values makes that a non-problem, however ugly some people consider it to be. If I see error assignments to _, that makes me raise my eyebrows.