DEV Community: Matronator

Why I Like Go

Matronator — Tue, 29 Jul 2025 01:10:08 +0000

A while back, I wrote an article titled Why I Dislike Go. It was an honest reflection of my frustrations at the time, after trying to use Go in some personal projects. I called out what I saw as shortcomings - verbose error handling, lack of generics (at the time), limited expressiveness, and a rigid design philosophy that felt like it was holding me back more than helping.

But things change.

I've since had the chance to use Go more extensively, and to explore some of its more modern evolutions, especially through XGo (formerly Go+). With more experience under my belt, I feel it’s only fair to revisit my earlier stance and share how my perspective has evolved. This article is not a retraction, but rather a follow-up - a continuation of my journey with Go, and why I’ve come to like it.

The Paradox of Go: Restriction Breeds Simplicity

One of the things that annoyed me the most originally was Go’s insistence on simplicity. It felt restrictive. I wanted tools for abstraction, generics, custom error types with stack traces, and all the bells and whistles I was used to in languages like TypeScript, C#, or even PHP.

But over time, I started to appreciate what Go doesn’t let you do. The simplicity isn’t just a constraint - it’s a design decision that leads to consistency, readability, and ease of onboarding for teams. The codebase is boring in the best possible way. After revisiting some Go projects months later, I found them easier to read and understand than many of my TypeScript or C# ones.

Go’s philosophy grows on you - and once you start thinking in Go, the clarity is liberating.

Generics: A Game Changer

Since I wrote that original post, generics have landed in Go. While they’re not as powerful or flexible as in Rust or C#, they are very Go-like: simple, focused, and designed to solve specific use cases rather than introduce abstraction for abstraction's sake.

They’ve enabled cleaner, more reusable code without sacrificing readability. I still wouldn’t use them everywhere - and Go doesn’t want you to - but when you need them, they’re there. And they work.

XGo (Go+): Go’s Friendly Cousin

One big shift in my attitude came from discovering XGo, the language formerly known as Go+. XGo is like Go’s more expressive younger sibling - it builds on Go’s foundation but does away with some of Go's more questionable or annoying syntax quirks.

For instance compare these two snippets and tell me that XGo isn't just nicer to look at and much easier to write than regular Go:

// XGo
arr := [1, 3, 5, 7, 11, 13, 17, 19]
m := {"Hi": 1, "XGo": 2}

// Go
arr := []int{1, 3, 5, 7, 11, 13, 17, 19}
m := map[string]int{"Hi": 1, "XGo": 2}

If you’re coming from a scripting or dynamic language background, XGo feels more welcoming, without losing Go’s strong typing and performance. You can write Go-style code, but with less boilerplate and more flexibility. It’s especially great for educational purposes, prototyping, and scientific or data-heavy applications.

For me, XGo rekindled my interest in Go by showing me what's possible with a slightly more expressive syntax, while still staying in the Go ecosystem.

Tooling and Ecosystem: Fast, Reliable, and Getting Better

One thing that never needed changing was Go’s tooling. go build, go test, and go fmt remain some of the smoothest developer experiences I’ve had. Everything just works, and it works fast.

The ecosystem has also matured. With the rise of microservices and containers, Go has firmly cemented itself as a go-to language for backend development. Libraries and frameworks are more plentiful and higher quality than when I first dipped my toes in.

Final Thoughts: From Critic to Convert

So, do I take back everything I said in my old article?

Not entirely. I still believe some of the critiques I made were valid - at least for how I felt and coded at the time. But Go is a language that rewards patience. It’s not flashy, but it’s solid. And in a world of over-engineered abstractions, Go’s “boring” approach is starting to feel more like a breath of fresh air.

If you bounced off Go in the past, I encourage you to give it another shot. Try it with a fresh mindset. Or better yet, dip your toes into XGo and see how expressive Go’s future might be.

You might be surprised - like I was.

Have thoughts or similar experiences with Go or XGo? I’d love to hear about them in the comments!

Why I dislike Go

Matronator — Wed, 17 May 2023 17:36:03 +0000

Update March 2024 - Since this article was written, I have worked a bit more with Go and found to actually enjoy the language despite my initial dislike of some of its quirks mentioned here.

As a programmer, I have worked with many programming languages over the years, and I have to say that Go (or golang) is probably one of my least favorite. In this article, I'll explain some of the reasons why I dislike Go, based on my own experience.

Syntax

One of the most significant issues I have with Go is its syntax. While it may appear simple at first, it can be unintuitive and confusing. The way it handles errors and null values can be frustrating, and the use of the := operator for variable declaration can be hard to read, especially for those coming from other programming languages. Additionally, Go lacks some essential features that are available in other modern programming languages.

Lack of Object-Oriented Features

Go's lack of proper object-oriented features is another significant issue that I have with the language. While it does use structs and interfaces to implement object-oriented concepts, it doesn't have traditional class hierarchies, which makes it challenging to write code that adheres to traditional object-oriented principles. The lack of classes and ability to extend them makes the language really hard to work with on more complex projects. This can be frustrating for developers who are used to working with other programming languages that have more robust object-oriented support.

Difficulty writing Object-Oriented code

In addition, Go's approach to object-oriented programming can make it difficult to write expressive and reusable code. For example, it doesn't support inheritance, which limits the ability to reuse code and create class hierarchies. Furthermore, it doesn't have method overloading or default parameter values, which makes it challenging to write reusable code..

Error handling and no exceptions

Another issue with Go is its error handling and lack of exceptions. While it's good that Go encourages checking errors, the way it handles it is a disaster. Instead of using exceptions like almost every other modern language, they went for checking errors with if conditions... This can make it difficult to handle errors gracefully and leads to (a lot) more code clutter. I would like Go much more if they added regular exceptions like any normal language, but I don't see that happening.

Organizing project

Go's project organization is another area that I find frustrating. There's no standard way (that I know of) of organizing your project files. Every third-party library I checked has a different approach. This can make the project a mess and hard to navigate, especially for larger projects.

Aesthetics and lack of features

Finally, I find the Go programming language to be aesthetically unappealing to put it mildly. Its naming conventions and package organization can be inconsistent and confusing, leading to frustration. Moreover, it lacks some of the elegant and expressive features found in other modern languages, making it feel cumbersome to use. Actually it lacks most of the features from other languages and the feature set it has is very limited (there's only one looping mechanism, no generics, no ternary operator, no default values for parameters, no function overloading, etc...).

It's not all bad

I don't dislike everything about Go though. Some features are quite nice. Like multiple return values, easy concurrency, fast compile times, that it compiles to executable binaries on every platform and speed, performance and small file size of the compiled programs.

In conclusion, while Go has its strengths, such as its built-in concurrency features and its focus on simplicity and performance, it's not a language that I enjoy working with. Go's syntax, lack of proper object-oriented features, difficulty in writing expressive and reusable code, error handling and lack of exceptions, messy project organization, and ugly syntax make it challenging for me to work with. Nonetheless, the choice of programming language ultimately depends on the specific needs of the project and the preferences of the developer.

Be sure to check out my latest project MTRGen - a PHP file generator.

Visit my portfolio if you want to see more projects like this and more.