Thanks for the comments. I take your point about OO, but I was aiming at producing a broad overview of Go which necessarily means simplifying in some parts. To 90% of developers today brought up on strongly typed languages such as Java and C#, OO means single inheritance type hierarchies.
I agree with your decision to not label Go as object-oriented; to too many people that term is simply synonymous with inheritance. But rejection of the term itself doesn't mean we should automatically reject the often-related concepts of encapsulation and polymorphism, both of which we can have without inheritance.
Specifically, you say this:
I can hear the die-hards screaming already about encapsulation, inheritance and polymorphism. It turns out that these things are not as important as we once thought.
And then you proceed to give examples that only attempt to refute the usefulness of type hierarchies, without addressing encapsulation and polymorphism. I'd be curious to know what facilities, if any, Go provides for these concepts.
Go doesn't support polymorphic methods but supports polymorphic types through interfaces. Encapsulation is through the private/public naming convention I refer to in the blog post.
I can hear the die-hards screaming already about encapsulation, inheritance and polymorphism.
Any die-hards screaming about all 3 of those should be viewed with a bit of skepticism. When I talked about this a lot, folks were "meh" about inheritance, especially class-based inheritance. The only thing I see as being worthy of die-hard adherence is polymorphism. Encapsulation is there to help enable polymorphism. I'll note that the degree of encapsulation varies amongst systems that call themselves OO.
Yes, but people are actually targeting single-inheritance as the predominant means of polymorphism? What happened to interfaces? (Plus things like Strategies.)
To me your "simplification" is a bit of a straw man.
