You should tell that to the Go team so they can stop doing it everywhere. Edit: I realize this came off as snarky, sorry. I'm somewhat serious though. In my c

You should tell that to the Go team so they can stop doing it everywhere. Edit: I realize this came off as snarky, sorry. I'm somewhat serious though. In my current Go installation I count 519 type switches in the standard library. Some exist for perfectly valid factoring reasons. For example, the x509 package switches on the type of the public key it receives in order look up some x509-specific values for encoding. It would be a layering violation for the public keys themselves to have x509-specific encoding values attached, and Go doesn't permit the x509 package to declare new methods on types defined in another package. (They _could_ define a new interface which extends PublicKey, and declare a new local wrapper type for each supported public key type, embedding the external ones then attaching methods as needed - but this is sufficiently clunky that I've never seen it done in Go core). But there are plenty of other cases, especially in the crypto packages, where the type switching seems gratuitous. For example the crypto.PublicKey interface is actually empty - 100% of public key functionality is implemented through some kind of type assertion or switching. Maybe there really is a good reason for this, but it's not obvious to me.