Like the author, I had the same problem when I was going through the GO tutorial as well (I have to say it's not the greatest tutorial for someone coming from a totally different programming background, I've never done C or Java for example). Interface in GO can be a little bit tricky to understand at first, but then they become kind of like a nice way of thinking about coding.

I can't help to think like what @tomp said. It's really up to the developers to annotate their code and document their Interfaces, specially when using a systems programming language like GO, comments are essential as the code is not as self-explanatory like Python or Ruby. GO provides an excellent tool to generate documentation from internal or external packages: http://golang.org/cmd/godoc/.

There's this great write-up on GO's Interface by Jordan Orelli: http://jordanorelli.tumblr.com/post/32665860244/how-to-use-i...

> No, this problem is faced by anyone that needs to read code code written by other developers.

No, it's not a problem for code readers. If you see a file being passed as an argument to a function which expects a Reader, you know that it implements Reader. Otherwise it wouldn't have compiled.

How to answer the question "Given type X what are ALL interfaces that it implements from the overall code"?

First off, why do you need to know? The whole point is that interfaces are in no way tied to the things that implement them.

Second, you can search for the function definition(s) that define the interface. Search for Write(p []byte) if you're looking for Writers.

If you're in control of the interface, you can just modify it slightly and see what breaks.

You still haven't said why you would need to find all implementations of an interface. "Because I'm new to the company" is not a reason.

The thing about interfaces is that the function that takes the interface is the thing that defines how it is used. The implementation of the type that implements the interface is irrelevant.

log.Logger writes logging output to an io.Writer. It doesn't care what the implementation of any particular writer is... the writer could be sending data across the network, it could be writing it to the console, could be writing to a file... doesn't matter. Logger just calls Write() and merrily goes about its business. Trying to look up all the implementations of the io.Writer interface is not useful when looking at log.Logger. They're mostly unrelated.

Now, if you're trying to figure out how to do some specific thing, like log to a Windows named pipe, then you'd want to start looking around your named pipe library to see if it implements Write().... which it almost certainly does.

Because in the enterprise world we have these boring projects with 60+ developers scattered around the world, high rotation of developers and new guys need to be able to jump into the code of several megabytes of text?

I think this could mostly be solved by automatic documentation generation tools and/or IDEs. Just like Java IDEs and JavaDoc index the world and show relations (i.e. classes that implement an interface), so could (and probably will) Go tools do so.

Well at least it is not only Java requiring IDEs then. :)

People are programming in completely dynamic, duck typed languages and say that these languages are best without IDE.

Funny you say that, because the first IDEs were actually invented for dynamic languages (Smalltalk & Lisp).