I wonder how long it'll take for some asshat to implement the equivalent of Prototype.js in Go -- forcing classicist modeling and inheritance in one of the few sanctuaries from its reign of terror.
I guess I'm not sure what the real value in implicit interfaces is. If I can define any number of interfaces on a type (as it is in most (all?) compiled languages), why does it really matter? By forcing an explicit declaration of an interface implementation, it actually adds to the ability to understand the type relationships in a program. Is there something I'm missing?
It matters because increasingly the programmer may not have either the ability or the desire to add yet another explicit interface onto some class. They may not have the ability because it may be in a library beyond their control. They may not have the desire because it already implements a billion other interfaces.
More to the point, there is a school of thought that looks upon the entire idea in modern OO type systems of organizing types into hierarchies and DAGs as being so much busy work that, at the end of the day, does not provide you with a useful means of expressing behavior. There are those of us who have drunk the kool-ade of aggregation and want to throw inheritance in all its forms into the trash and keep interfaces, the thing we actually use sometimes.
From that perspective (my perspective, emotional and flawed), go's interfaces make all the sense in the world. They look delicious.
The argument that they are making is that people are starting to choose dynamic languages because of "clumsy type systems". Since every relationship has to be spelled out in excruciating detail you spend a ton of time changing and tweaking these relationships. Implicit interfaces, in theory, address this problem.
