Go 1.25 Release Notes

Original Article ↗ Hacker News Discussion ↗

Release timing and packaging

  • Some noticed the GitHub tag existed before binaries appeared on go.dev, joking about “Schrödinger’s release.”
  • Minor meta-discussion about people not reading the article before commenting, and desire for AI-generated comment summaries.

New GC and JSON features (experiments)

  • Interest in the experimental “greentea” garbage collector (enabled via GOEXPERIMENT=greenteagc), though the name is barely surfaced in the notes.
  • Strong excitement about encoding/json/v2 and the GOEXPERIMENT=jsonv2 flag:
    • Promises better performance and streaming.
    • Adds flexible custom marshal/unmarshal functions for types you don’t own.
    • Allows preserving JSON key order via a workaround.
  • Clarification that jsonv2 experiment has two parts: swapping in the new implementation behind encoding/json (intended to be backwards compatible except for error text) and exposing the new v2 API, which is explicitly not yet stable and expected to evolve based on feedback.
  • Mention that previous experiments (arenas, synctest) show experiments can change or be abandoned.

Language, ecosystem, and documentation

  • Many express long-term satisfaction with Go’s incremental, conservative evolution and strong tooling.
  • Others note frustrations: poor or outdated docs for many third-party libraries; IDE/copilot-style tools sometimes suggesting nonexistent members.
  • Some counter that Go’s standard library and pkg.go.dev documentation are generally excellent and that tests/examples often suffice.
  • Several say Go culture de-emphasizes third-party dependencies; the standard library solves most needs.

Abstractions and design philosophy

  • Debate over “Go discourages abstractions”:
    • One side argues Go downplays deep, layered abstractions and metaprogramming, leading to simpler, more readable code and shallow stacks.
    • The opposing view is that discouraging richer abstractions harms maintainability and forces ad-hoc reinventions, especially in large systems.
    • Nuanced middle ground: Go supports abstractions but encourages them to be “wide and shallow” rather than deeply nested.

Stability, longevity, and versioning

  • Multiple anecdotes of being able to rebuild many-year-old Go code with no changes, seen as a major advantage (especially for ops).
  • Some warn that new v2 packages in the stdlib may create parallel “v1 vs v2” knowledge burdens, though older code usually wraps the new implementation and still works.
  • Tools like modernize can automate migrations (e.g., from io/ioutil).
  • Discussion of go.mod’s go x.yy line:
    • Concern that libraries may bump minimum Go version unnecessarily, mirroring Rust’s “MSRV” issues but without a strong Go culture around minimum supported versions.
    • Others say most popular Go libraries keep minimum versions low (often 1.13+).

Networking, TLS, and standards vs reality

  • MX lookup change: LookupMX now returns MX records whose “names” look like IP addresses.
    • Previously these were discarded per RFC; now they’re passed through because real DNS servers sometimes do this.
    • Some worry this is intentionally non-compliant; others argue being “reality compliant” matters more than strict RFC adherence in practice.
  • TLS changes welcomed: servers now prefer the highest shared protocol version, and both clients/servers are stricter about spec compliance while remaining interoperable.

Tooling, AST access, and concurrency helpers

  • Praise for Go’s analyzer framework and accessible AST tooling; contrasted with other languages where AST use is rarer despite APIs existing.
  • Comparisons with Lisp (code-as-data) and Lua sparked a side-discussion, but Go is still seen as unusually strong in practical tooling around its AST.
  • New WaitGroup.Go helper is appreciated for reducing boilerplate launching goroutines under a waitgroup; some wish errgroup were in the standard library given the ubiquity of error returns.