Go 1.22

Original Article ↗ Hacker News Discussion ↗

Go 1.22 introduces several notable language and standard library changes, including `for` loops that can range over integers, experimental range-over-function iterators, improved HTTP routing in `net/http`, and new helpers like `sql.Null[T]`, while also tightening slice and I/O behaviors. Engineers largely welcome the release for preserving Go’s hallmark of simple, productive tooling—automatic toolchain upgrades, fast builds, strong stdlib—especially compared with the configuration-heavy TypeScript/JavaScript ecosystem. At the same time, some express concern that features like iterators and new range forms may slowly erode Go’s minimalism and its strong backward-compatibility guarantees, which are now partly managed via `go.mod` version gates and environment flags.

Interactive release notes

  • A community-made interactive version of the 1.22 notes (with runnable/editable examples) is widely praised as making changes—especially subtle ones like for-loop variable semantics—much easier to grasp.
  • Some confusion around slice functions like Compact/Replace is clarified: shrinking functions now zero out elements between old and new length.

Adopting new Go versions & OS constraints

  • Many production users upgrade quickly, sometimes immediately or after the first point release, relying on tests and easy rollback (container images, CI).
  • Some organizations standardize on one Go version across repos; others let individual services move faster.
  • A notable blocker is support for older OSes (e.g., Windows 7, Server 2012, older macOS), forcing some to stay on 1.20 for years despite security concerns.
  • The new toolchain auto-download via go.mod is seen as making upgrades very easy, though downstreams can be hurt when libraries bump required versions without gains.

New language features (range, iterators, sql.Null)

  • for range over integers is welcomed as a familiar for x in range(10)-style construct; some find it ambiguous and unnecessary versus classic for i := 0; i < 10; i++.
  • Edge behavior (e.g., negative integers resulting in zero iterations) is noted.
  • “Range over function” iterators excite those wanting proper iterators and lazy sequences; others dislike the added complexity and functional style, finding it verbose compared to yield in C#/Python.
  • sql.Null[T] is appreciated; patterns that distinguish “unset” vs “intentionally null” are discussed for partial updates.

HTTP routing and stdlib evolution

  • Enhanced routing patterns in net/http are welcomed; several hope to drop third-party routers like chi/Gorilla mux.
  • Concern arises that changed path semantics (e.g., {} handling) and other behavior tweaks strain the Go 1 compatibility promise, even though they’re gated by go version and GODEBUG flags.

Go vs TypeScript/Dart and language philosophy

  • Multiple commenters contrast Go’s minimal, opinionated design and unified tooling with the JS/TS ecosystem’s heavy configuration, library choice, and increasingly complex type systems.
  • Some miss map/filter-style slice helpers and like libraries such as lo; others argue these create a secondary “DSL” and prefer explicit loops for clarity.
  • Dart and modern Java are cited as examples where feature accretion and multiple ways to do things make code harder to understand and refactor; Go is praised for reducing “cleverness” and aiding shared understanding, though a few find Go’s verbosity “legalese” compared to Python.

Tooling, embed, and performance tweaks

  • go:generate and go:embed are highlighted as major productivity wins: generating code from protobuf/XSLT and bundling web assets, eBPF, or SQL migrations into single binaries.
  • The standard library’s ongoing micro-optimizations (e.g., io.Copy using Linux splice for certain socket pairs) are appreciated as “free” performance.
  • Some worry that stdlib special-casing is hard to replicate outside it, but accept it as expected.

Compatibility concerns & open questions

  • The changed for-range variable semantics are seen as a pragmatic fix for common bugs but technically a breaking change; some argue Go should use major version bumps rather than accumulating environment flags.
  • A question about whether a specific Go 1.21 Linux memory issue is fixed in 1.22 is raised; the thread does not provide a clear answer (unclear).