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!
Top comments (0)