UUID package coming to Go standard library

Original Article ↗ Hacker News Discussion ↗

Go’s plan to add a UUID package to its standard library is prompting debate over what belongs in a “batteries included” language and how much the core should grow. Supporters argue that a standardized UUID type (especially for v4 and v7) improves interoperability, safety and reduces reliance on unmaintained or vulnerable third‑party libraries, particularly for server and database use. Skeptics worry about long‑term API stability, evolving UUID standards, and whether such functionality is better kept outside the core to avoid locking in design mistakes.

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.