Go is my hammer, and everything is a nail

Original Article ↗ Hacker News Discussion ↗

Treating Go as a “one hammer for all nails” provokes both praise and skepticism. Many engineers value Go’s simplicity, fast tooling, strong standard library, and easy deployment as reasons to standardize on it for backends and CLIs, arguing that deep expertise in a single ecosystem beats constant context switching. Others counter that Go’s limitations in areas like GUIs, data science, numerics, and richer type systems make it a poor universal choice, and that the real leverage comes from picking different languages and platforms where they fit best.

Go as a “one hammer” language

  • Many agree the post is less about Go specifically and more about the strategy of specializing in one ecosystem to reduce context switching and increase productivity.
  • Several commenters say Go is “good enough” for most backend, CLI, and networking tasks, with fast compile times, simple semantics, and strong batteries-included tooling.
  • Others argue that almost any general-purpose language (Java, C#, Python, Kotlin, etc.) could fill this same “hammer” role; Go just happened to be the one the author knows best.

Comparisons to other languages

  • Go vs Python: Python often wins for small scripts, data science, and prototyping; Go is preferred for larger, long-lived systems, deployment as single binaries, and performance.
  • Go vs Java/C#: Some see Java/C# as more expressive with richer standard libraries and better GUI stories; Go wins on simplicity, compile speed, and deployment ergonomics.
  • Go vs Rust: Many see them as occupying different niches (Rust closer to C++; Go closer to Java/Node). Rust is more powerful but harder to learn and slower to iterate.
  • Several note that Go’s early tooling influenced others (e.g., formatters in JS/TS, Rust), and that Go was once ahead but is now “average good” among modern ecosystems.

Language design, ergonomics, and error handling

  • Supporters like Go’s constraint: minimal features, explicit code, no operator overloading, simple concurrency model (goroutines + channels), explicit error returns.
  • Critics find Go verbose and unexpressive, especially for data wrangling, JSON handling, and numerical code. Repeated if err != nil and lack of higher-level collection APIs are common complaints.
  • There is ongoing debate around error handling as values vs exceptions; some praise Go’s clarity, others see it as C-style boilerplate.
  • Generics are seen as a major improvement, but some still consider the type system primitive compared to Java/C#/Rust/TS.

Ecosystem strengths and gaps

  • Strong points: standard library (HTTP, TLS, x509, net), tooling (go command, gofmt, modules), culture of idiomatic, stdlib-first code, easy cross-compilation, small static binaries.
  • Weak points: desktop/mobile GUI (Fyne, Wails, etc. seen as immature or niche), data science/ML (no robust dataframe ecosystem), 3D/game dev and FFI-heavy, low-level systems work relative to C/Rust.

Specialization vs breadth

  • Several emphasize that deep expertise in one stack pays off over years; others warn that exposure to multiple paradigms and languages broadens perspective and improves design.
  • Some note a downside of knowing many languages: constant “language choice anxiety” and endless re-evaluation instead of shipping.