As of Saturday, March 7, 2026, Go’s long-running crypto/uuid proposal is still open, tagged Proposal-FinalCommentPeriod, and getting fresh comments about one surprisingly consequential question: should the standard library choose a UUID default for you?
That matters because Go has made it to 2026 without a built-in UUID package, which means every team still picks a third-party dependency and quietly standardizes on its own little house style. The live argument is not “should Go support UUIDs?” It is “how much choice should the standard library hide for me?”
The boring gap that never really made sense
The official proposal issue is titled proposal: crypto/uuid: add API to generate and parse UUID. That title sounds small, but the missing package has been annoying for years because UUIDs are not exotic. They are routine plumbing. People use them for API resources, database rows, tracing, queue payloads, and anything else that needs a stable identifier without central coordination.
In most languages, that means the standard library or platform eventually grows a blessed option. In Go, developers have mostly bounced between third-party packages and internal wrappers. That works, but it also creates the kind of low-grade fragmentation that Go usually tries hard to remove.
I think that is why this proposal has legs. It is not chasing novelty. It is trying to clean up a boring but universal part of day-to-day programming. The issue has also become more concrete because the current discussion now references RFC 9562, which formalizes the newer UUID story developers now have to think about.
The real fight is not UUIDs themselves
The part I find more interesting is the argument happening inside the proposal thread right now. One camp wants an opinionated New() so developers who “just need a UUID” do not have to read an RFC before writing a line of business code. The other camp thinks a generic constructor hides a meaningful tradeoff, especially now that the RFC 9562 world includes both the familiar random v4 and the increasingly practical time-ordered v7.
That is a very Go argument. It is really a disagreement about whether the standard library should reduce friction or force clarity. If you hide the decision, you help beginners and cut package churn. If you make the version explicit, you teach people that UUIDs are not one thing anymore.
One March 7 comment in the Go issue makes the pro-default case bluntly: “If I don’t have specific needs and all I want is a uuid, I really don’t want to have to learn anything about the tradeoffs involved.”
I get that view. A lot of developers are not trying to become UUID historians. They want one safe answer that keeps a service moving. But the opposing side is not being pedantic for fun either. v4 and v7 really do encode different priorities. Very roughly, v4 leans toward randomness and privacy, while v7 gives you time-ordering that can be friendlier for storage and indexing.
| Position | Why people want it | What it risks |
|---|---|---|
uuid.New() default |
Keeps common code simple and gives teams one obvious path. | Can hide the privacy and ordering tradeoffs between UUID versions. |
uuid.NewV4() and uuid.NewV7() |
Makes intent explicit and forces a conscious choice. | Pushes ordinary app developers into a decision they may not care about. |
Hacker News found the practical fault line fast
The Hacker News thread got to the real engineering tradeoff almost immediately. One early comment argued that v4 is still the safer default for privacy and random distribution, especially in distributed systems. Another pushed back that v7 can be much friendlier for ordered inserts and storage locality, which matters if you have spent any time watching a database fight random primary keys.
The clearest HN summary was short and practical: “v4 is the goto, and you only use something else if you have a very specific reason.”
That is the part I like about this debate. It is not fake drama. It is two different production concerns colliding. Random IDs are good for some workloads. Sortable IDs are better for others. A standard library package turns that difference into API shape, and once it ships, the language is effectively teaching that choice to everybody.
The current GitHub comments on March 7 sharpen that same split even more. One side argues that most users just want one blessed function and should not have to learn UUID versioning on day one. The other side argues that a generic New() would hide a real tradeoff from exactly the people who need to understand it before they copy the first snippet into production.
This is really a standard library philosophy test
I do not think the hardest question here is technical. It is philosophical. Go’s standard library works because it saves people from bikeshedding common choices, but it also has a long tradition of avoiding convenience APIs that paper over real complexity. That is why this UUID proposal feels more revealing than it should. It exposes what Go developers actually want from the stdlib in 2026.
Do they want the standard library to be a place where common boring things become default and invisible? Or do they want it to stay sparse enough that versioned tradeoffs remain visible in code? You can make a case either way. I lean slightly toward giving people a sane default plus explicit alternatives, because the package fragmentation tax has been silly for too long.
At the same time, I understand the caution. If uuid.New() lands and silently implies one version, that choice will get copied into thousands of services by people who never read the docs. In Go, API shape becomes habit very quickly.
| Version | What it optimizes for | Why people care in this proposal |
|---|---|---|
v4 |
Randomness and low metadata leakage | Feels like the safer generic default if the stdlib wants one obvious answer. |
v7 |
Time ordering and friendlier write locality | Looks attractive to people who care about ordered inserts and modern database behavior. |
My take
I think Go should add the package. That part feels overdue. The language gains nothing from making every team rediscover the same third-party dependency for such a common task. But I also think the proposal debate is doing real work. It is forcing the Go team to decide whether the standard library should optimize for fewer imports or better mechanical clarity.
If this lands well, the win is not just a uuid package. The win is a cleaner answer to one of those tiny questions that keeps showing up in reviews, templates, and starter repos. If it lands badly, Go will end up standardizing a choice that half the community still wants to argue about. Either way, this is one of those small proposal threads that tells you a lot about the language around it. I would watch the proposal issue itself over the next few days, because whatever API shape survives final comment period will say a lot about what kind of convenience the Go team is willing to bless.
- Go having no standard UUID package in 2026 has been weird for a long time.
- The important debate is not whether UUIDs belong. It is whether the stdlib should pick a default on the developer’s behalf.
- If this package ships, the API shape will teach Go programmers which tradeoff the language thinks is normal.
Sources and follow-up reading
- Go proposal issue for
crypto/uuid - Hacker News discussion
- Related Reddit discussion about the role of Go’s standard library
Discover more from TheFlipbit
Subscribe to get the latest posts to your email.