Go is finally getting native UUID support in its standard library after more than six years of community requests. Proposal #62026, updated February 25 and trending on Hacker News today with 303 points, now carries a “Likely Accept” status. This ends Go’s status as the outlier among major programming languages—Python, Java, C#, JavaScript, and Ruby all include UUID support in their standard libraries.
The acceptance matters because 55,000+ packages depend on the third-party google/uuid library. That’s not a nice-to-have feature—it’s a fundamental building block for distributed systems that Go has stubbornly refused to provide natively.
Why Go Resisted (and Why That Was Reasonable)
Go’s philosophy centers on a minimal, stable standard library with backwards compatibility forever. Adding to the standard library creates multi-decade API commitments that are nearly impossible to evolve. When the language rejected UUID requests in 2018 and earlier, the reasoning wasn’t arbitrary—it was philosophical.
However, “the language prioritizes stability and backwards compatibility forever,” as one Hacker News commenter noted, “making stdlib additions significant long-term commitments rather than casual additions.” The concern was legitimate. Moreover, when RFC 9562 updated the UUID specification in May 2024, it vindicated worries about API lock-in. Standards do evolve, and premature standardization can trap you.
Nevertheless, there’s a difference between caution and obstinacy. Every other major language managed to include UUIDs without catastrophic API failures. Consequently, Go’s conservative stance had crossed from prudent to dogmatic.
What Changed: Ubiquity Wins Arguments
Three factors shifted the calculus. First, the google/uuid package hit 55,000+ dependent packages—an undeniable signal that UUIDs aren’t optional infrastructure. As one developer observed, “Go is rather the exception than the norm” regarding UUID support. Furthermore, when you’re the only holdout, maybe you’re wrong.
Second, RFC 9562’s publication in May 2024 provided a stable, modern specification. The standard addresses contemporary distributed computing needs with new versions like UUIDv7, which offers superior database performance through time-ordered sortability. Additionally, a mature standard reduces the API evolution risk that justified earlier rejections.
Third, Go itself matured. At 16+ years old, the language has proven it can maintain backwards compatibility while pragmatically expanding its standard library. In fact, Go 1.25 added a faster, more flexible JSON v2 package—proof that the “minimal at all costs” era is ending.
Technical Details: Which UUID Versions?
The main proposal targets UUID versions 3, 4, and 5 in a new crypto/uuid package. However, an alternative proposal suggests focusing only on UUIDv4 and v7 generation without parsing, aligning with RFC 9562’s recommendation to treat UUIDs as opaque identifiers.
Meanwhile, the debate isn’t settled. UUIDv7 offers superior database performance through time-ordered sortability (faster B-tree indexing), while UUIDv4 provides maximum randomness without timestamp leakage. One Hacker News commenter proposed a pragmatic hybrid: “Use v7 internally, then scramble it before sending to users”—database performance plus privacy protection.
Developers should watch which approach wins. The choice reflects broader API design philosophy: minimalism (generation-only, simpler API) versus completeness (full parsing, feature parity with google/uuid). Given Go’s track record, expect the conservative option.
Community Reaction: Pragmatic Support
The Hacker News discussion (191 comments) shows overwhelming support tempered with legitimate technical concerns. Developers express relief but raise important questions about API lock-in if RFC evolves again, whether parsing is necessary, and which versions to prioritize.
Notably, one developer pointed out real-world consequences of unmaintained UUID libraries: “The Python uuid7 library implemented a draft RFC that later changed, creating incompatibilities between Python versions.” This validates concerns about standardizing too early, though RFC 9562’s recent publication mitigates this risk.
The Go community isn’t cheerleading blindly. The concerns raised—API lock-in, version choice, parsing necessity—are technically sound and will influence the final implementation. This is pragmatism, not fanboyism.
What’s Next for Go UUID Support
No official release date exists, but “Likely Accept” status with “Proposal-FinalCommentPeriod” suggests Go 1.24 or 1.25, likely arriving in 2026 or early 2027. Once landed, this will reduce reliance on google/uuid for new projects, though the third-party package will remain for legacy code.
Nevertheless, the broader signal matters more than UUID support itself. Go is evolving from doctrinaire minimalism to pragmatic recognition of fundamental developer needs. Therefore, when a language resists for six years before accepting overwhelming evidence, that acceptance signals genuine philosophical shift.
Expect more pragmatic standard library additions as Go matures. Consequently, the minimalist-at-all-costs era is ending. Developer experience finally won an argument.
