A fresh critique of the Go programming language is gaining attention not because it uncovers a new bug or proposes a replacement, but because it revisits a long-running dispute over whether Go's simplicity has always come with unnecessary costs. In a July 2025 essay resurfacing in wider developer discussion, Thomas Habets argues that the language still falls short on several fundamentals, from variable scoping to resource cleanup, portability quirks and memory efficiency.[Source 16848]
The article is explicitly an opinion piece, and the supplied evidence supports reporting it that way. Habets says he has been criticizing Go for more than a decade and presents the new post as a continuation of that argument rather than a one-off reaction. His central complaint is that many of Go's pain points were not hard tradeoffs forced by circumstance, but design choices the software industry already knew how to avoid.[Source 16848]
One of the most concrete examples in the extract concerns variable scope and error handling. Habets argues that Go often leaves `err` variables live for longer than necessary, which he says makes code harder to read because experienced programmers must stop and check whether an out-of-scope-looking value is reused later. In his view, this is not just syntactic irritation but a recurring source of ambiguity when reading for bugs.[Source 16848]
The essay broadens from syntax into system behavior. Habets criticizes Go's handling of `nil`, conditional compilation via file comments, and the reliance on `defer` for resource cleanup. He argues that developers are forced to remember which objects need explicit cleanup and how that cleanup behaves, instead of relying on more uniform patterns. The extract also says Go programmers must still write code that is safe in the presence of panics even though the language is often marketed as not having exceptions in the traditional sense. That mismatch, for Habets, leaves developers exposed to the downside of exception-style control flow without giving them what he sees as a better ergonomic model.[Source 16848]
Another part of the critique addresses data handling and infrastructure cost. Habets says that treating arbitrary binary data as strings can contribute to silent data loss around non-UTF-8 filenames, drawing on his own experience. He also pushes back on the idea that memory use is no longer a serious concern, arguing that RAM still matters in cloud environments and dense container deployments where memory translates directly into cost. The extract says he has even rewritten some services in another language because the Go version consumed more memory over time.[Source 16848]
None of those claims, in the supplied evidence, are independently benchmarked or countered by Go maintainers. That limits how far a straight news report can go. What is firmly supported is that a detailed and sharply worded critique has struck a nerve by arguing that widely accepted aspects of Go remain poorly designed from the perspective of a veteran systems programmer.
The significance of the post is therefore cultural as much as technical. Go has become entrenched in cloud tooling, backend infrastructure and developer platforms. A critical essay landing in that context does not prove the language is failing, but it does highlight that adoption has not settled the debate over whether Go's celebrated minimalism is clarity or accumulated compromise. Habets' answer is unambiguous: the industry knew better, and Go still shows it.[Source 16848]
