Just Use Go

Overall sentiment on Go

• Many see Go as a solid, “boring” default for backends, CLIs, and devops tools: simple, fast to compile, and good enough at many tasks.
• Others find it dull or actively unpleasant to write, especially in large codebases, and say it becomes hard to maintain at scale.
• Several participants note that language choice rarely matters for typical CRUD apps; many mainstream languages are “good enough.”

Language design and ergonomics

• Praised for simplicity and a small core language that’s easy to keep in one’s head.
• Criticized for:
  • Lack of enums and sum types / algebraic data types.
  • Odd export-by-capitalization convention.
  • Mediocre module/package system and GOPATH history.
  • Limited metaprogramming; generics added late and seen by some as the “wrong” priority vs enums.

Error and null handling debates

• The explicit if err != nil style is a major flashpoint:
  • Supporters say explicit errors-as-values aid static analysis, avoid hidden control flow, and match modern “no hidden exceptions” guidelines.
  • Critics say it creates noisy boilerplate, encourages copy‑paste handling, and doesn’t truly “force” correct handling; errors can still be ignored.
• Nil/null handling is widely disliked:
  • Zero values can mask missing data.
  • Pointer-based nullability feels awkward.
  • Interface/nil semantics are surprising and can break logical expectations.

Ecosystem, tooling, and deployment

• Strong points: fast compilation, good cross‑compilation, static-ish binaries, long-lived services that “just run,” good standard library for networking and backends.
• Weak points:
  • Weaker story for full-stack web (asset pipelines, rich ORMs, migrations) compared to frameworks like Django or .NET’s EFCore.
  • Complaints about ecosystem maturity, old-OS support, and CVE handling for fat static binaries.
  • WebAssembly support described as poor.

Comparisons with other languages

• Java / Kotlin / .NET:
  • Some argue Java/.NET are equally or more “boring” and productive, with stronger ecosystems and better error or type systems.
  • Others prefer Go over Java’s historical complexity and .NET’s heavier tooling and “bloat.”
• Rust:
  • Frequently cited as safer, faster, with better error handling (Result/?) and richer types.
  • Many say LLMs reduce Rust’s boilerplate cost, eroding Go’s simplicity advantage; but Rust’s dependency bloat and review difficulty are concerns.
• Python / Node / TS:
  • Go often preferred over these for backends due to performance and deployment simplicity, but Python dominates AI/data science and has better CUDA/C ecosystem integration.
  • Node/TS still attractive where shared frontend/backend language or rich JS tooling matters.

Concurrency and performance

• Goroutines and channels are widely liked; easy to use multiple cores and hit high request rates.
• Others note race conditions and shared-state bugs are still easy to write; Go doesn’t magically solve concurrency design.

AI, agentic coding, and Go

• Multiple comments say LLMs write Go code very well: the language’s simplicity and consistent patterns work in agents’ favor.
• Some now pick Go primarily because AI tools handle it reliably, even for sizable projects.
• Others argue agents handle Rust and TypeScript well too, weakening Go’s relative advantage.

Critiques of the article’s framing

• Several push back on “just use Go” as overly narrow and dismissive:
  • Emphasize choosing the language that fits domain requirements, team skills, ecosystem, and tooling.
  • Note that not all work is web backends; systems, games, embedded, and formally verified code often need different choices.
• Some see the post (and similar rants) as flamebait or possibly AI-generated, and call for evaluating content on substance rather than hype.