First, the grievances expressed by the author can be solved by better documentation tools: http://godoc.org/image/gif#Decode http://godoc.org/image/gif#Decode c

First, the grievances expressed by the author can be solved by better documentation tools: http://godoc.org/image/gif#Decode http://godoc.org/image/gif#Decode clicking "io.Reader" will take you to its definition, pretty useful when navigating messes like xgb. The author has avoided reading the "Learning Go" documents on the Go website which explains these differences from other languages http://golang.org/doc/ http://golang.org/doc/ . I'd like to argue against writing explicit implementation annotations in code unless really necessary. If the author had read the documents I mentioned earlier, he would have read this: http://golang.org/doc/effective_go.html#interface-names http://golang.org/doc/effective_go.html#interface-names and realised that any value that implements io.Reader will have a function called Reader, no need for messy lists of code annotations describing lists of interface implementations. The authors complaint is somewhat like complaining that a car is not sold with the text "this goes into a garage" because otherwise they couldn't know- you'd expect the Car to implement the Volume interface the Garage takes so you could check. To me, the way interfaces function is more intuitive. The author's problem is that they are solving the problem in reverse, it is strange to me that they would start the problem of reading a GIF from the end of 'decoding it' and not the end of 'reading it from something', the point of io.Reader is that it represents anything that can be read, whatever method he uses to read a GIF, be it out of a buffer, a connection, or a file will return a value that implements io.Reader if it is good code.