Forty year old Gang of Four patterns, designed for C++, misunderstood and poorly implemented by Java programmers continue to drag down the world of computing in 2023.

Many of these "Patterns" are even considered anti-patterns and poor design choices in every language (Singleton), but you insist on flexing your new found Go knowledge less than 20 hours after writing your first hello world by posting about "Patterns in Go - Singleton" and embarrassing yourself.

1. Almost every one of these “patterns” are not idiomatic for Go.

2. They are not even Object Oriented Patterns, but people keep posting them as they are.

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 ).

Object Oriented programming is actually not even 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 creator of the term. Not by itself, but it does make it considerably more “Object Oriented” than C++ or Java.

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.

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) 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.

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.

As a former Java main, it is embarrassing …

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.

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.

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. Singleton.

Just to make sure my point is 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.

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 Singleton 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.

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.