Message passing between lightweight execution contexts, coupled with ability to create and destroy these contexts dynamically, is basically the actor model.
Programming languages tend to approach the expression problem in one of two ways: OO-languages tend to focus on making it easier to implement the same operations using different data types (e.g. "object I can click on with a mouse" might be a scrollbar, a window, a menu, a text-box, etc. - same operation, different data representations), while functional languages tend to focus on easily implementing new operations against the same underlying data types. By abandoning class hierarchies, Go seems to end up more on the "functional" side of this divide.
As Adam Crossland indicated in his comment, "type-ignorantly-implementing-interface" can be considered a form of duck-typing, which is highly prevalent in dynamic languages. (It's more technically correct, though, to consider this as a structural type system within Go. C++ templates are probably the most popular implementation of a structural type system today.)
Go has plenty of antecedents - I don't think any one of its ideas are original to the language. But I think that's generally the wrong measure for a language intended to be practical. Go looks like it mixes useful ideas from several different domains together in an elegant way, that (I think) would result in more productive programming than C# or Java might yield. I hope it gains traction.