It's sort of Go-specific, but the same style is also used in Haskell using typeclasses, Scala/Ruby/etc using mixins/traits, and C++ using templates.
Rather than inheriting from some base class, you just make sure your class can do certain operations and then other stuff works on that- it's good way to decouple algorithms, containers, etc. from the types they work with.
The comments in his code are reminiscent of programming by contract (an idea I believe Djikstra himself was fond of). In Go the types of the interfaces are statically checked, which is good (in Python or Ruby, this isn't the case), but the contract the interface represents has to remain in comments and unit tests.
It would be nice to be able to specify tests that every implementor of the Heap interface must pass?
I am a fan of programming by contract myself, but I'm not quite sure it could be pasted onto Go's interfaces quite so simply. In the case of Heap perhaps it could be done in a straight forward way, but what about more generic things that have more to do with side-effects?
Alan Kay talks about field effects but maybe what he really means is that "everything is an object" is a mistake. Not everything is an object in real life. For example, a sound wave is not an object but objects can react to it (or it can manipulate them, whichever you prefer). Maybe emphasizing this in a programming language can be done as simply as you have described it is done in go. ( I have always found objects expressive and useful but when overused they feel like a straitjacket)
A sound wave may not be an object, but it is a noun and has properties such as frequency and amplitude. Though I could imagine defining a sound wave as a function.
A sound wave could be considered an object depending on your problem ___domain. The point is that operations should be able to work with anything that has the operations it needs defined. A sound wave could have several operations defined on it, including one(s) that let it behave as a function.
Duck typing is one form of it, yes. But interfaces are not always inferred- Go has you specify the interfaces themselves, Haskell typeclasses have you specify the implementation, but it's still the same idea.
