Fourteen Years of Go

Original Article ↗ Hacker News Discussion ↗

Fourteen years after its release, the Go programming language is widely seen as “boring but reliable” infrastructure: easy to learn, fast to compile, with strong tooling and a standard library that powers much of today’s cloud and DevOps ecosystem (Docker, Kubernetes, Terraform and more). Commenters contrast Go’s deliberately minimal feature set with richer but more complex languages like Rust, Java, and Python, debating trade-offs around generics, the lack of sum types and null safety, error handling, and concurrency ergonomics. Many view Go’s backward compatibility and single-binary deployment as major strengths for long-lived backend services, even as others criticize its design limitations and Google’s central role in its evolution.

Language popularity & perception

  • Posters note that Go attracts both enthusiasm and “language bashing,” often framed as “Go is not Rust.”
  • Some argue bashing is a sign of popularity and of teams being forced to use Go when they’d prefer something else.
  • Several see Go as having moved into the “boring but safe” category: less hype, widely used, less advocacy.

“Modern” status and peers

  • Go is seen as one of the youngest mainstream languages compared to Java/Python/C++.
  • Often contrasted with Rust, Swift, Kotlin, Java, C#, JavaScript, and Python in terms of features, safety, and ecosystems.

Learning curve & developer experience

  • Many report Go as very easy to pick up, especially for PHP/Python/Java/C developers.
  • Others struggle with Go and/or Rust syntax/semantics and are advised to pick one, not both, and build real projects.
  • Tooling (formatter, linter, IDE support, test/bench harness) is repeatedly praised.

Strengths commonly praised

  • Fast compilation and small static binaries.
  • Solid standard library, especially for networking and HTTP.
  • Simple deployment (single binary), good fit for cloud-native and CLI tools.
  • Concurrency primitives (goroutines, channels) seen as powerful, with good performance.
  • Backwards compatibility of Go 1 is highlighted as a major asset.

Criticisms & missing features

  • Frequent complaints about:
    • nil and lack of option/result types or null safety.
    • Weak enums and absence of sum types/pattern matching.
    • Verbose, easy-to-forget error handling (if err != nil).
    • Rough edges in interfaces, generics, and reflection.
  • Some see Go as too restrictive/minimal; others appreciate this as reducing over‑engineering.

Concurrency & panics

  • Debate over whether Go truly has “great concurrency ergonomics.”
  • Comparisons to Erlang/Elixir suggest Go’s primitives are easy to use but hard to use correctly, with risks of races and deadlocks.
  • The fact that an unrecovered panic in any goroutine crashes the whole program is seen as a significant design wart; there’s an extended debate on whether panics should ever be recoverable and how this compares to Rust.

Design philosophy, ecosystem & longevity

  • Repeated emphasis that Go deliberately keeps the feature set small, prioritizing readability and maintenance over expressiveness.
  • Some worry about reliance on Google; others argue the open-source status and widespread adoption make its future relatively safe.
  • Go is viewed as excellent for back-end services, infra/devops tools, and “getting things done,” but not a strong fit (today) for ML, scientific computing, graphics, or heavy desktop/embedded work.