TL;DR

Stop posting about “Patterns in Go” that are nothing more than verbose Java boilerplate ported to Go syntax and do not even use proper Go idioms.

People keep posting “Patterns in Go - XXXXX” articles.

1. They are not even Object Oriented Patterns, but people keep posting them as they are.
2. Those “patterns” are not written in idiomatic for Go.
3. And even if they were, as it is very easy to discover, Go is not an Object Oriented language; or is it?

What is Object Oriented then?

The language decisions that were made when the Go syntax was created were a direct reaction to the the wasteful verbose boilerplate of C++ (and ironically inheritance of the same things in Java, but worse, at least all the additional boilerplate is in a single file now ).

Object Oriented programming is actually not about the Objects it is about message passing.

I regret the word 'object'. It gets many people to focus on the lesser idea. The real issue is messaging. Messaging is the abstraction of the communication mechanism. It's what allows different parts of a system to interact without knowing anything about each other. That's the power of objects, and it's what makes them so useful.

— Alan Kay in an interview with Peter Seibel for Dr. Dobb's Journal in 1997.

So why are C++ and Java called “Object Oriented”?

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

— Alan Kay, OOPSLA '97

If C++ is not what you should think about when hearing “Object Oriented” then neither is Java. Especially since Java does not have “message passing”.

Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS. — Alan Kay in an interview with Peter Seibel for Dr. Dobb's Journal in 1997.

Guess what does? Go. Specifically goroutines, and they were inspired by Erlang processes.

Does that make Go “Object Oriented” by the definition of the creator of the term. Not by itself, but it does make it considerably more “Object Oriented” than C++ or Java. Especially whey they disavow both languages as meeting their original conceptual criteria.

Way more, if you consider other statements he made on the definition later. Lets look for more evidence to support my argument.

So what should C++ and Java be called? Well that is enough for another article or more, but anything else would be a way better term, given what the inventor of the term says.

I personally think “Class Type Oriented” would be semantically more appropriate considering Alan Kay focuses on the term “class” even less than “object” and C++ and Java are all about classes and type systems first and foremost and objects are just a side effect of instantiating classes to them.

So what does Alan Kay think defines an “Object Oriented” language in his own words?

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

— Alan Kay from an email to Stefan Ram on 2003-07-23

How would you do that in Go?

Make every struct field non-exported (starts with a lowercase letter in its name), this translates to package private you Java wonks, and have nothing but exported functions that work with the hidden data. Make every function take an Interface and return nothing but struct that implements an exported Interface .

To spell it out:

• only messaging: Export only functions and Interface which is just a collection of function signatures that are public, so you are effectively passing functions or collection of functions to functions, thus messaging.
• local retention and protection and hiding of state-process: non-exported struct fields meets all these criteria outside the package level, package == local.

• extreme late-binding of all things: this one is one that is tricky from a practical stand point.

  Alan Kay admits that difficulty is what motivates this requirement. “(I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)” - from an email to Stefan Ram on 2003-07-23

  The original design of the Go language to allow inference of Interface implementation via “duck typing” was to eliminate a lot of the pain, mostly boilerplate, associated with static typing.

  Go is a static type safe language; it does not do exclusively late-binding, much less extremely. For non-trivial sized code bases, you find out very quickly, whatever you are gaining with extremely late-binding, you lose much more by not having compile time checks. In Go there are ways to do late binding, but you have to use interface{} or with generics any in all those places which makes you question your choices in life very quickly. duck typing and now generics is a decent compromise between the two extremes.

So what languages are “Object Oriented” as per clarifying statements by the originator of the term?

The one that I am most familiar with because I have written real world production applications with is Erlang. I learned it because it was created for real world scenarios that needed 9 “nines” uptime. I learned it because thing I needed to create, it needed similar uptime. I am sure that other Functional languages will be mentioned in the comments, but it is the only one I have first hand experience with in a deployed commercial production environment.

*Why am I not an Erlang main now? *

It is not that practical a language to work in for things that do not demand the features that make it unique. Very few projects demand the extreme uptime and massive concurrency that Erlang provides, but there are costs to consider. Another article worth of costs at least.

As a former Java main, it is embarrassing …

What you are pushing is not even “Object Oriented” it is a perversion of it to the point that it is not even recognizable.

It is especially embarrassing when your implementation does not even begin to use Go idioms and ignores go specific things that were implemented specifically to do the thing you think you are being “informative” about and showing your competence, when you are just exposing the opposite and promoting misinformation to the most vulnerable, those that know less then you. Providing LLM with even more misinformation at the same time.

Please stop pushing “Object Oriented Pattern Implementations” on Go like you are informing the ignorant and unwashed masses that have been using Go for the past 10+ years and saving them from themselves. It is embarrassing, I say that as a former Java main myself. And you wonder why Java programmers get a bad rap?

What triggered the compulsion to post this article.

Let us take the most beloved Gang of Four Pattern of all time. Especially to the Java faithful. The one most people have their first epiphany with when introduced to “Patterns Of Reusable Design”; probably because it is the easiest to comprehend and abuse. Singleton.

Just to make sure my point is not misinterpreted this is not about Singleton,

My point is about the articles that are nothing more than terrible ideas in Java ported to Go syntax. They are still Java examples.

For this example:

Let us ignore the fact that it was a terrible anti-pattern when it was first documented, because it is by definition global state and the #1 goto Java pattern. “Singleton Considered Harmful” has been a thing for decades. See what I did there; goto, singleton

Let us also ignore the fact that in the JVM you can not even implement Single correctly because by design the JVM can not guarantee that one and only one instance of a class is ever created. Here is a hint to the all the self professed Java experts that are about to write a comment about how I am wrong; Multiple Classloaders.

If you see someone post “Patterns in Go - Singleton” first look at the implementation they post; if you do not see sync.Once() anywhere in the code, then let them have it in the comments!

That is what you should call them out on, their promotion of misinformation. The hubris in posting a “teaching” article about something they barely know the basics on. That is a malicious disservice to those that know even less than they do.

The rest of the internet has already proven all the other points, that is why I prefaced this with “Let us ignore …” caveats.

I tried to research everything in this article for factual accuracy, but I am sure the internet will tell me what their opinion about it is. If there are any factual inaccuracies, and you want to point them out in the comments, provide the source and I will correct them. Otherwise, do not waste everyone else’s time. If it is important enough to correct, it is important enough to site sources like I did for the quotes and technical specs.