Not really. It’s a terrible approach that permits some really, truly awful patterns that the designers should have known better than to permit. But it’s not really “go is dynamic!”
they are "duck typed" .... so an object automatically implements an interface if it has methods with the right signatures to satisfy the interface.
It's handy if you need to add interfaces onto code you don't control (say, library code) as you can avoid a whole layer of adapter types / functions that you need in true statically typed languages.
But I'm curious if its a great idea in the long run to have interfaces being "accidentally" implemented by objects. Doesn't seem like it would stand up well to refactoring or various other scenarios.
Than it’s the age-old war between nominal and structural typing. The latter can be really comfortable and productive, but as you note, it may be less safe (eg. just because I have a next method doesn’t mean I want to make it an iterable or something like that. It can easily break class invariants)
Isn't this more "structurally typed" rather than "duck typed"? From what I've seen, duck typing implies dynamism, while structual typing implies static types. Go is clearly statically typed. So no, Go interfaces are not dynamically typed, they are structurally typed, which is static.
