&gt; Because Go gives us interfaces and closures we can write much more elegant, generic APIs with a flavor similar to Ruby or Lisp and this is the direction the language naturally wants us to take. Personally I like to use the empty interface for plumbing and only pin things down to specific interfaces or concrete types where I need to for performance or correctness.<p>That&#x27;s a lot like using opaque pointers in C. What is it about Go that makes people assume it&#x27;s shortcomings are beautiful designs?<p>I learned yesterday that `x == nil` can return false <i>even if x is nil</i> so long as x is an interface type. But it depends on whether x is <i>actually</i> nil or a nil value with a specific type.<p>(╯°□°）╯︵ ┻━┻<p>My other pet peeve is that a method with a non-pointer receiver that tries to modify the receiver object will silently drop those modifications on the ground, because the object is copied. Which makes some sense, except that Go likes to convert to pointer receivers automatically, so the caller can&#x27;t tell that anything is wrong. The only difference is one character in the method definition. Everyone I know hits this bug at some point and loses half an hour before they learn to look for it. You could almost say &quot;all method receivers must be pointers&quot; except that you need to refer to interface types without the pointer.<p>(╯°□°）╯︵ ┻━┻