One of the few nice things about the C include mechanism is that it's pretty easy (and standard practice) to set up separate implementation and interface files. If the implementation of something changes, but not the interface, I don't want to have to recompile all the clients. This is lost in almost all "modern" languages.
(This is, of course, horribly broken in C++ which likes to inline everything.)
As far as I can tell, there are 2 advantages to the separated header file, implementation file pattern in C. First, you get easy documentation of a library's API, and second, the advantage that you mentioned (implementation changes do not necessitiate a full recompile).
I would argue that both of these (or atleast the core of these) is addressed by Go.
For documentation, there is a simpler way to get at a library's public API; an automated program that extracts that API and presents it in a web page (or in your console). See http://golang.org/pkg/unicode/utf8/ for an example (for completeness, here is the file it is generated from http://golang.org/src/pkg/unicode/utf8/utf8.go)
For avoiding unnecessary recompiles, Go solves this problem by making compiles really fast, rendering this problem moot.
The only advantage Go interfaces have over interfaces in other languages, is that you can make third party code comply to a given interface if you're lucky enough to have the same set of methods available.
Even then, you might hit the issue that although the interface matches syntactical, the semantic meaning of the method calls differs.
For the CS folks, Go interfaces are nothing more than structural typing, available almost any FP language.
The only advantage over Java, C#, D is that you are not required to state explicitly which interfaces a given type implements.
However this forces you to use tools to discover which interfaces a given type implements.
(This is, of course, horribly broken in C++ which likes to inline everything.)