UUID package coming to Go standard library

Original Article ↗ Hacker News Discussion ↗

Status of the UUID Proposal

  • Thread centers on adding a uuid package to Go’s standard library.
  • Linked issue is marked “likely accept,” so inclusion is expected unless something major changes.
  • Many welcome it, especially for UUID v4 and v7 support in a server‑oriented language.
  • Some care more about a standard UUID type (with JSON/Text/sql integration) than about generation itself.

Motivations: Maintenance, Security, and Interop

  • Prior UUID libraries in Go have gone unmaintained and even had security issues; unmaintained packages implementing draft specs caused incompatibilities in other languages too.
  • A stdlib implementation is seen as:
    • More trustworthy and maintained.
    • Less vulnerable to dependency hijacking and name squatting.
    • A stable interop point across the ecosystem.

Go Standard Library Philosophy (“Batteries Included” or Not?)

  • One side argues Go is annoyingly minimal and missing “basic stuff” like UUIDs, WebSockets, better logging, JWTs, GUI, etc.
  • Others counter that Go’s stdlib is comparatively strong (especially networking/crypto) and intentionally conservative to reduce long‑term maintenance.
  • Comparisons made with Python, C#, Java, Rust, JavaScript, PHP; disagreements over which has the “best” stdlib.

API Design and Stability Concerns

  • Strong concern: once a UUID API enters stdlib, it effectively can’t be changed; Go culture resists “v2” APIs.
  • Some want a very small surface: RFC‑correct v4 generation via crypto/rand, basic v7, parse/format, JSON/Text/sql hooks, but no legacy or privacy‑problematic variants.

UUID Versions, Databases, and Privacy

  • v4 defended as the default for randomness, privacy, and as recommended by several distributed databases.
  • v7 promoted for time‑ordering and better B‑tree/index locality; trade‑offs include encoded timestamps that may leak timing information.
  • Deterministic (hash‑based) UUIDs and custom schemes (e.g., encrypting integer IDs, UUIDv47) mentioned for specific use cases.

Critiques of UUIDs and Alternatives

  • Some participants dislike UUIDs entirely:
    • Too long and human‑unfriendly for debugging, UIs, or paper.
    • Overused where simple integer counters or DB sequences would suffice and perform better.
  • Suggestions:
    • Random 16‑byte IDs with custom encoding (base32/58).
    • Human‑readable prefixed IDs or word‑based IDs for usability.
    • Centralized “take‑a‑number” style ID services.

Meta: Tone and Bikeshedding

  • Several comments note the amount of drama and bikeshedding typical of Go discussions.
  • Some see the thread as an example of Go’s cautious governance; others find the debate over such a small feature excessive.