Go Proposes Adding UUID Support to Standard Library

The Go team is considering adding UUID support to the standard library, addressing a long-standing gap that has forced developers to rely on third-party packages for this common functionality.

The Proposal

The proposal, currently tracked as golang/go issue #62026, suggests adding a crypto/uuid package to generate and parse UUID identifiers, specifically versions 3, 4, and 5. The main argument for inclusion is that the most popular third-party package, github.com/google/uuid, has become a staple import in virtually every server and database-based Go program.

As one contributor noted, "Pretty much every other language does, and tends to include it as part of its crypto library." This observation highlights how Go stands out as an exception among mainstream programming languages in not providing native UUID support.

RFC 9562 Compliance

The proposed implementation would follow RFC 9562, the latest UUID specification. The package would generate random components using cryptographically secure random number generators, ensuring the same security standards as other crypto operations in Go.

Historical Context

This isn't the first time UUID support has been proposed for Go. Previous attempts in issue #23789 and issue #28324 were rejected, with maintainers questioning what concrete benefits bringing in a third-party package would provide. The concern was that third-party packages are easy to import and can have more flexible release cycles than the standard library.

Community Debate

The proposal has sparked significant discussion within the Go community. Some contributors argue that if developers must import UUID functionality externally every time, it might as well be part of the standard library. Others point out that UUID versions 1, 2, 3, 4, and 5 are becoming outdated, with version 7 being the most promising for future development.

Alternative Approaches

A related proposal, crypto/rand: add UUIDv4 and UUIDv7, suggests a more limited approach focusing only on UUID generation rather than parsing. This aligns with RFC recommendations to treat UUIDs as opaque identifiers whenever possible.

Technical Considerations

The discussion has revealed several technical considerations:

• Whether to include a Generator type for more flexible UUID generation
• Support for fallible generators that can return errors
• The potential need for functions that accept specific timestamps for version 7 UUIDs
• Balancing simplicity against feature completeness

One contributor from the gofrs/uuid project suggested adding a NewV7AtTime(time.Time) function to support generating UUIDs from specific timestamps, a feature their library provides that the current proposal doesn't include.

Current Status

The proposal has been moved to the "Incoming" stage in the Proposals project, indicating active consideration by the Go team. While there's no consensus yet on all details, the core idea of adding UUID support to the standard library appears to have significant backing.

Why This Matters

For Go developers, this proposal represents a potential simplification of dependency management and a standardization of UUID handling across the ecosystem. Currently, projects must choose between multiple third-party UUID libraries, each with slightly different APIs and feature sets. A standard library implementation would provide a common foundation that all Go projects could rely on.

The debate also reflects broader questions about the scope of Go's standard library and how the language balances simplicity with functionality. As Go continues to grow in enterprise adoption, the need for common utilities like UUID support becomes increasingly pressing.

Looking Ahead

If accepted, the crypto/uuid package would likely follow Go's typical approach of providing a minimal, well-designed API that covers the most common use cases while leaving more specialized functionality to third-party packages. The inclusion of version 7 support would also ensure the implementation remains current with evolving UUID standards.

The Go team's decision on this proposal could have ripple effects throughout the Go ecosystem, potentially reducing the need for external dependencies and providing a more consistent developer experience across Go projects of all sizes.