Go Kind Of Sucks

TL;DR

Nil interfaces are singled out as a major source of confusing bugs because calling through them can yield bizarre errors that take time to interpret.

Briefing Cornell Notes

Briefing

Go’s biggest “sucks” aren’t framed as fatal flaws so much as a cluster of tradeoffs that show up once real systems hit production constraints—especially around nil handling, concurrency ergonomics, and the practical friction of integrating Go with surrounding ecosystems. A recurring theme is that many complaints come down to explicitness: Go’s error handling and type-driven control flow feel verbose to people coming from exception-style languages, but that same explicitness is credited with making failure modes more predictable.

One standout gripe is Go’s treatment of nil interfaces. Calling methods on a nil interface can fail in confusing ways, producing errors that take time to diagnose—so the nil-interface behavior is described as Go’s “single greatest mistake.” Closely related is the broader idea that Go’s correctness depends on disciplined, consistent patterns: for example, reliable error wrapping and stack traces require programmers to be consistent with wrapping practices, since the language won’t automatically enforce it.

Concurrency is another pressure point. Several participants agree that Go’s goroutines and channels are powerful, but the ergonomics can be awkward in specific scenarios. Channel-based designs can encourage arbitrary buffering and overuse of concurrency primitives, and there’s frustration around converting I/O abstractions into channels—turning an io.Reader or io.Writer into a channel pipeline often means writing custom reader/writer “pumps.” There’s also debate about context management: goroutines may outlive their intended scope unless context is passed and honored, and “automatic” cancellation is seen as something people wish existed.

Garbage collection performance and memory behavior also draw criticism, particularly for complex allocation patterns. The discussion suggests that certain heap graphs—like structs containing pointers to structs that contain pointers—can make garbage collection more expensive because the collector must traverse large object graphs. Arenas are mentioned as a potential mitigation, but the group notes that arenas have been largely “said no to,” while still expressing hope for a renewed proposal.

Beyond runtime behavior, the conversation touches on tooling and style friction in large codebases: defer is praised as useful but also criticized as a frequent source of bugs and contributor mistakes, and Go’s formatting/casing quirks (including operator spacing) are singled out as annoyances. Some complaints are treated as “skill issues” rather than language defects—such as flaky tests caused by inadequate synchronization—while others are treated as inherent to the language’s design.

The closing takeaway is pragmatic: every language has pain points, and Go’s critiques often reflect where it sits on the tradeoff map. Experience helps teams avoid many issues, and despite the gripes, Go is still recommended as a “fine language,” with the strongest complaints concentrated in nil-interface pitfalls, concurrency ergonomics, and the explicitness that makes error handling feel heavier than exception-based approaches.

Cornell Notes

Go’s most serious pain points cluster around explicit failure handling and concurrency ergonomics, with nil interfaces singled out as the most confusing source of bugs. Error handling is described as “verbose” mainly because it’s explicit—errors are values that must be handled—yet that explicitness is also credited with making failures more predictable than exception-style control flow. Concurrency critiques focus on channel usage patterns (buffering and overuse), friction converting io.Reader/io.Writer into channels, and the need to manage goroutine lifetimes via context. Garbage collection concerns center on allocation patterns that create pointer-heavy object graphs, where traversal costs can rise; arenas are discussed as a possible remedy but remain contentious. Overall, the discussion treats Go’s issues as tradeoffs that improve with experience rather than as a universal dealbreaker.

Why are nil interfaces described as uniquely problematic in Go?

The discussion highlights that a nil interface can still be “non-nil” at the interface level, so calling methods can produce bizarre errors that don’t immediately reveal what went wrong. It’s portrayed as a long debugging journey: the failure mode is not obvious, and it takes time to realize the interface contains a nil concrete value (or similar mismatch) rather than a truly nil interface.

What does “Go error handling is verbose” mean in this conversation, and why do some participants disagree?

Critics call it verbose because errors must be handled explicitly at each call site, often leading to longer control-flow blocks. Supporters counter that the verbosity is a feature: errors as values make failure handling explicit and consistent. The comparison is made to try/catch-style languages where it’s harder to know what a library might throw, leading to broad try/catch wrapping and awkward patterns.

What specific friction appears around channels and I/O abstractions?

A concrete complaint is that it’s hard to take an io.Reader or io.Writer and turn it directly into a channel. The workaround described is building a custom reader/writer that “pumps” data into a channel, which adds boilerplate and feels unnecessary when the goal is simply to stream data through channel-based concurrency.

How does goroutine lifetime management come up, and what’s the wish?

Goroutines can continue running after the scope that “should” own them ends unless cancellation is wired in. The conversation suggests context is the mechanism—passing context so goroutines can stop when the context is done—but notes that this requires discipline. The wish is for more automatic handling of goroutine retention/cancellation to reduce reliance on programmer skill.

What allocation patterns are blamed for garbage collection performance issues?

The discussion points to complex heap graphs: structs containing pointers to structs that contain pointers, creating large object graphs. When the collector runs, it may need to traverse many linked objects, increasing GC cost. Arenas are mentioned as a potential improvement because they can reduce per-object GC pressure, though arenas are described as having faced resistance.

Where do “skill issues” enter the critique?

Flaky tests are used as an example: if concurrency assumptions aren’t synchronized correctly, tests can become flaky, and the blame is placed on inadequate synchronization rather than the language itself. Another example is that context management and correct concurrency patterns are treated as learnable practices—problems often diminish as teams gain experience.

Review Questions

Which failure mode involving nil interfaces is described as hardest to diagnose, and why does it mislead debugging?
How do participants reconcile the claim that Go error handling is “verbose” with the argument that explicit errors improve predictability?
What are the two most concrete channel-related pain points mentioned, and how do they affect real I/O pipelines?

Key Points

1
Nil interfaces are singled out as a major source of confusing bugs because calling through them can yield bizarre errors that take time to interpret.
2
Go’s error handling feels verbose mainly because errors are explicit values that must be handled at each call site, unlike exception-based control flow.
3
Channel-based concurrency can lead to awkward patterns, including arbitrary buffering and extra boilerplate when converting io.Reader/io.Writer into channel streams.
4
Goroutine lifetime management often depends on disciplined use of context; without it, goroutines may outlive their intended scope.
5
Garbage collection performance concerns are tied to pointer-heavy object graphs that require more traversal during GC cycles.
6
Arenas are discussed as a possible mitigation for allocation/GC pain, but they remain controversial in proposals.
7
Many concurrency problems (like flaky tests) are treated as synchronization mistakes that improve with experience rather than unavoidable language defects.

Highlights

Nil interfaces are described as Go’s most dangerous “gotcha,” producing errors that are unusually hard to trace back to the real cause.

The “verbosity” complaint about Go error handling is reframed as explicitness: errors as values make failure handling predictable compared with try/catch-style uncertainty.

Channel ergonomics can be painful for I/O pipelines—turning io.Reader/io.Writer into channels often requires custom pumping code.

GC slowdowns are linked to pointer-rich heap graphs, where traversal costs rise; arenas are floated as a remedy.

Despite the gripes, the overall stance is that Go’s tradeoffs are manageable and improve with experience, and no language is portrayed as a true silver bullet.

Topics

Go Error Handling
Nil Interfaces
Channels
Goroutine Lifetimes
Garbage Collection
Arenas
Defer