[moron4hire]

On point #2:

I don't know anything about Go, but I've spent a lot of time working in a lot of languages. Structural typing is a bad idea. There are a few, limited cases where it's necessary, e.g. we have it in TypeScript because TS ultimately has to work within the limitations of JS. But if you don't have those sorts of limitations, intentionally implementing structural typing in your language is borderline negligent.

Interfaces don't just define a bag of method signatures. Interfaces are semantic, too. An Employee, a Gun, and a ClayPot might all have a method named `fire()`, but they all mean different things. But with structural typing, we can load our Employees into a Kiln and give HR a Gun to downsize the company, and nothing will stop us.

[sa46]

The upside of structural typing, with some help from Go idioms, is that it encourages composition and narrow types. A type like bytes.Buffer implements Reader, Writer, ByteWriter, ByteReader and another 5 or so interfaces but the call site can declare which set of methods it needs.

The downside of nominal interfaces seems worse: you have to import the interface which can lead to awkward situations like cyclic dependencies and type-only packages (a la Haskell). In practice, the extra friction of nominal interfaces also seems to encourage wide interfaces in contrast to Go's narrow interfaces.