DEV Community

loading...

Discussion on: The Problem with Interfaces, and how Go Fixed it

Collapse
emasoft profile image
Emasoft

@Ruotger Deecke: Well said. The author of the article doesn't seem to realize the trouble Go programmers are gonna get in with this.

Let me make an example.

If I have an "Audio" object (parsed and instanced from a random file in a folder) and a "AnimatedGif" object (from the same folder), and both have a "Play" method, I can easily happen to pass the "Audio" object to the "AnimatedGifVisualizer" by error, because both classes have a "Play()" method.

This will work fine until the "Play()" method would be actually called, suddenly crashing everything. And you will NEVER found why. Replace this for any similar scenario using any other data types, locally or server side, and you get the same silent, untraceable crash. This implicit interface conformance thing is a debugging hell.

This is why Go will never compete with better designed langages like Swift.
Because while who designed Swift really thought about this when created Swift protocols, Go designers just throwed in features because those sounded nice at first sight, with no careful assessment of consequences.

Collapse
dean profile image
Dean Bassett Author

If an error happens on your part, it isn't Go's fault for being designed badly, it's most likely yours. In order to crash the system in your example, you need to put your Audio struct in a place called AnimatedGifVisualizer...

In Go, methods have very clear meaning about what they do. If you see a method that's called CloseThenExit(io.Closer) in an io library, would you really pass in your Door struct which has a Close() method?