Go has done what most programming languages aspire to: spark emotionally charged debates. Let’s walk through the arguments and see what’s really being said.
1. Go Is Boring, and That’s Not Good
The author laments Go’s simplicity, equating it with boredom. One has to wonder: is the author looking for a programming language or a theme park? It’s almost as if the lack of flashy syntax and endless ways to do the same thing (read: Java’s 75 ways to write a loop) has robbed them of the joy of feeling “clever.”
What really shines through here is a deep yearning for glue code—the kind that stitches together massive, overly abstracted frameworks where the “fun” lies in deciphering dependency trees and watching IDEs buckle under their own weight. The thing is, Go’s “boring” design is what makes it productive. One way to loop? Great! Let’s loop efficiently instead of philosophizing over whether we should map, reduce, or just throw a lambda at it. However, let’s not ignore that map, reduce, and lambdas aren’t the simplest constructs for less experienced programmers. In enterprise scenarios, where turnover tends to be high, there will inevitably be individuals inexperienced with Go and even programming in general. This kind of knowledge can significantly increase ramp-up time.
And that Reddit quote about simplicity? It’s amusing that the author leans on the opinion of an internet stranger as if it’s gospel. Because nothing screams “reasoned argument” like citing a random Reddit user as your ace-in-the-hole.
2. Clean Code Principles Are Discouraged
The audacity to blame Go for “discouraging” clean code because of explicit error handling is peak irony. Apparently, if code isn’t wrapped in ten layers of abstraction, it’s cluttered. The real gripe here isn’t that Go discourages clean code; it’s that Go refuses to indulge in dogmatic object-oriented programming principles where “just hide it behind an interface” is the solution to everything.
Explicit error handling isn’t clutter; it’s clarity. Don’t get me wrong, I also have my fair share of critiques about how error handling works in Go, especially since it depends heavily on the discipline of the programmer. In this regard, my current favorite approach is that of Zig. But I understand—writing if err != nil is tedious if you’re used to sprinkling try-catch like salt on spaghetti code. Perhaps the real discomfort comes from not being able to toss exceptions around like a hot potato.
3. Go Is Purposely Small, and That’s a Problem
Ah, the classic lament of the orphaned framework fanatic: While I don’t know the original author of the post personally, the overall impression they leave is of someone deeply attached to frameworks (or any productivity shortcut). Why doesn’t this language do everything for me? The post criticizes Go for being “purposely small” and forcing developers to create their own solutions. Imagine the horror—a programming language that expects you to program! I'm not even debating the problem with dependecy hell of put a new library on the project for a 10 lines function.
The insistence that “batteries included” should mean “every possible middleware ever invented” reeks of the “not my problem” mentality: “I don’t want to build it, I just want to use it.” Sure, Go doesn’t include every single tool you might ever need, but that’s by design. Go gives you a sharp, efficient toolkit, trusting that you’re capable of building the rest. Go challenges developers to think about solutions, rather than just patching together existing libraries. This can feel like a curse to those accustomed to the mantra: 'It’s someone else’s problem; I’ll just use what exists and ship features without a second thought.' If you want a Swiss Army knife, there are plenty of bloated frameworks waiting for you.
4. Go’s Package Ecosystem Isn’t Mature
The post compares Go’s package ecosystem to the likes of Java’s and .NET’s, lamenting the lack of polished, ready-to-use libraries. Yes, Java and .NET have decades of accumulated cruft—uh, I mean, maturity. But Go’s ecosystem, while younger, has rapidly grown into one of the most active and innovative programming communities. Companies like Alibaba and ByteDance have built robust Go ecosystems, demonstrating its capability to support large-scale, production-grade systems. Perhaps the author limited their search to what FANG companies use, overlooking thriving communities in other parts of the world, especially in East Asia, where Go has seen significant adoption.
The complaint about “abandoned GitHub projects” is laughable. Have you ever tried looking for JavaScript libraries? It’s like walking through a graveyard of “Last commit: 2014.” Abandoned projects exist everywhere, but in Go, you’re empowered to write what you need instead of endlessly Googling for a package that’s mostly duct tape.
5. There’s Only One Way to Do Things
The contradiction here is delightful. The post swings between lamenting Go's opinionated simplicity and criticizing its lack of standardization, which is like arguing a chair is too sturdy and not flexible enough. First, Go is criticized for being opinionated and “limiting choice” with its design philosophy. Then, the author bemoans the lack of standardization in testing—as if Go’s philosophy should now dictate how they test. Which is it? Too much convention or too little?
Also, let’s clarify: Go’s design philosophy isn’t about limiting creativity. It’s about guiding you toward simplicity and maintainability. The endless debates mentioned in the post aren’t Go’s fault; they’re a result of developers clinging to conflicting practices instead of embracing Go’s straightforward approach. Again, this feels like someone who prefers rigid guidelines and a top-down cultural mandate for how to use a language, much like Sun Microsystems did with JavaBeans.
6. Debugging Is Not Fun
Debugging in Go is “not fun,” according to the post, which then bizarrely equates this to debugging in C. Debugging in C# or Java from the command line is equally painful. Honestly, I don’t feel any difference debugging Go code using a modern IDE like those from JetBrains. Perhaps I missed the point the author was trying to make. Yes, Go can use GDB, but it also has modern tools like Delve, which the author conveniently ignores. The real issue here isn’t Go’s debugging capabilities; it’s that the author prefers a language with a different approach to traces and errors in general.
Yes, Rust’s error messages are objectively better—but that doesn’t make Go’s approach inferior.
(And just out of curiosity, Rust’s approach to error handling seems to have learned a lot from Elm rather than from any perceived 'mistakes' in Go.)
Final Thoughts
The post boils down to one thing: a refusal to step out of the comfort zone of ready-made frameworks and POO dogma. The author wants productivity at the cost of understanding, preferring to duct tape together prebuilt solutions rather than embracing the power and simplicity of writing their own.
But here’s the thing: Go isn’t trying to be everything to everyone. It’s not trying to be the latest shiny object. It’s a tool designed to build reliable, maintainable, high-performance software—and it does that remarkably well. If you want a language that caters to your every whim, Go probably isn’t for you. But for those who value simplicity, clarity, and performance, Go will always be a go. That said, I totally respect their worldview and acknowledge that there are always tradeoffs between productivity and control. Go emphasizes control and simplicity, and that might not align with everyone’s priorities—and that’s perfectly fine.
BTW, why anyone chooses Go for webdev or for prototyping stuff? There are always our script friends (rails, django, node-ish solutions)
Go is not here to entertain. If you find Go boring, maybe it’s not the language.
Ultimately, I hope the author finds their way with the tools that bring them joy and productivity—nothing I’ve written here is personal, just my perspective on their critiques.