Go Programming – Paradigm Characterized by Go

goobject-orientedterminology

I'm intrigued by the way Go abandons class hierarchies and seems to completely abandon the notion of class in the typical object oriented sense. Also, I'm amazed at the way interfaces can be defined without the type which implements that interface needing to know.

Are there any terms which are/can be used to characterize this type of programming methodology and language paradigm (or perhaps specific aspects of it)? Is the Go language paradigm sufficiently new and distinct from the classical OOP paradigm and sufficiently important in the history of computer programming to warrant a unique name?

Best Answer

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.