Go is not an object-oriented language

I’ve spent the better part of my career working with object-oriented languages. I was exposed to them first through Visual Basic. From there, I learned Java, then C#, and then C++. Along the way, I made a deliberate study of object-oriented design, drinking deeply from the design patterns promulgated by the Gang of Four, and learning to reshape everything I did in terms of object-oriented design. It’s the way I think about, decompose, and solve problems.

When I started learning Go (https://golang.org), I approached it from this same mindset, and at first it felt like I was making some traction. In time, though, I discovered it wasn’t working. I kept running up against brick walls where it felt like I was almost there, but the wall between what I was trying to accomplish and what Go could do was simply too high.

The problem wasn’t Go. The problem was that I was trying to treat Go like an object-oriented language when it isn’t. Some ideas that commonly appear in object-oriented languages, like interfaces, misled me. The sort of “pseudo-inheritance” that happens when you embed one structure into another made me feel like maybe I could treat the embedded structure as a base class and the embedding structure as a subclass. But while these things hinted at or “smelled” like object-orientation, they really weren’t.

I had to approach Go on its own terms. It is not an object-oriented language. Structures in Go aren’t not polymorphic the way that objects are in C# or C++. Embedding is not the same thing as subclassing. Structures are not classes.

I have a way to go still. 20+ years of an object-oriented habit is hard to break. But it is essential to succeed in using Go. As I approach Go on its own terms, I find myself less frustrated, and I start to see the patterns of use in Go that will help me achieve my goals. I start to see Go’s strengths more than its weaknesses.

My advice to anyone coming to Go from an object-oriented background like mine is to leave that thinking at the door lest you find yourself making things needlessly complicated and thoroughly frustrating. Approach Go with an open mind.

Go is not an object-oriented language