It's not that simple. I mean, given an os.File and a function that requires an io.Reader, it's pretty straightforward to discover that square peg goes in square

It's not that simple. I mean, given an os.File and a function that requires an io.Reader, it's pretty straightforward to discover that square peg goes in square hole. But just given either half of the relationship it's not currently so easy: "This function needs an io.Reader, how would I get my hands on one of those?" Go doesn't currently have an easy way to tell you. "This os.File has a bunch of stuff implemented. What can I do with it?" Go doesn't currently have an easy way to tell you. The hard problem that remains to be solved is discovery. Someone somewhere needs to take a good long look at your project, the libraries available on your computer, and the standard library and connect the dots. It should be possible, most IDEs have this for other languages, when Go grows up you would expect these to be flagship features: "Find all known implementations of a given interface" and "Find all interfaces this type satisfies." For example, you might eventually expect the locally generated versions of these two pieces of documentation to refer to each other, even though they currently do not: http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader http://golang.org/pkg/os/#File http://golang.org/pkg/os/#File godoc already aggregates all your local packages' documentation into one place, adding cross-references to known implementations seems like an obvious incremental addition.