UUID package coming to Go standard library

> UUID versions 1, 2, 3, 4, 5 are already outdated.

Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues.

Edit: Context links for reference, these recommend UUIDv4:

https://www.cockroachlabs.com/docs/stable/uuid

https://docs.cloud.google.com/spanner/docs/schema-design#uui...

A slow day in Go-news land? :)

It is heathwarming to see such mundane small tech bit making front page of HN when elsewhere is is debated whether programming as profession is dead or more broadly if AI will be enslaving humanity in the next decade. :)

One thing I love about Go, not fancy-latest-hype features, until the language collapses or every upgrade becomes a nightmare, just adding useful stuff and getting out of the way.

Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.

That's great, but I abhor UUID's.

I see them crop up everywhere. IMO, they are decidedly human-unfriendly - particularly to programmers and database admins trying to debug issues. Too many digits to deal with, and they suck up too much column width in query results, spreadsheets, reports, etc.

I'm not saying they don't have a place (e.g. when you have a genuine need to generate unique identifiers across completely disconnected locations, and the id's will generally never need to be dealt with by a human). But in practice they've been abused to do everything under the sun (filenames, URL links, user id's, transaction numbers, database primary keys, etc). I almost want to start a website with a gallery of all the examples where they've been unsuitably shoehorned in when just a little more consideration would have produced something more humane.

For most common purposes, a conventional, centralized dispenser is better. Akin to the Take-A-Number reels you see at the deli. Deterministic randomization is a thing if you don't want the numbers to count sequentially. Prefixes, or sharding the ID space, is also a thing, if you need uniqueness across different latency boundaries (like disparate datacenters or siloed servers).

I've lost count of how many times I've seen a UUID generated when what the designer really should have done is just grab the primary key (or when that's awkward, the result of a GetNextId stored procedure) from their database.

Based on the conversation, is it actually coming?

Golang lack of support for basic stuff like this is quite annoying.

Wonder about the opinion of the maintainers of the Google package. Will they put it on maintenance mode or continue developing it like usual?

Kotlin also added RFC 9562 (which includes the new UUID versions) support to the standard library in version 2.3 recently. It's a multi platform implementation too so it works on native, wasm, jvm and js. I think it makes a lot of sense to default to that now that the IETF RFC has been out for a few years.

So, it makes sense for Go to introduce support for this as well.

Is there a way to have benefits of both? Version 7 for better database clustering. And version 4 for complete randomness? So users can not inference nothing from the id? I have an idea: Use version 7 internally, then scramble it before sending to the user. Scrambling could be done by the database or by the server application. It could be as simple as XOR with some 128bit constant, or as resilient as AES encryption. Of course you also need to do unscrambling of IDs coming from users.

Cool! I love go and things like this will keep bringing me back :)

Every time I've implemented UUID's it's for a database and something like PostgreSQL would handle it. Still glad to see this feature being worked on, I would have utilized a random string generator instead of the full battle tested UUID specification.

Seems pointless. Go should focus on refactoring core libraries, especially net and http, for performance because nbio, gnet and others are kicking its ass. And that is sad, as third party libraries should never perform better than standard library.

Also swiss tables were great addition to Go's native maps, but then again there are faster libraries that can give you 3x performance(in case of numeric keys).

Go is often the best part of my work day.

what a bunch of drama in the comments.

Am I the only one who hates UUIDs and doesn't see the point of them?

Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else.

Argh.

Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate.

I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languages for interoperability so it makes sense to have that in the standard language.

Anyways, I'm just happy we'll get generic methods after 10 years of debates, I suppose. Maybe we'll get an export keyword before another 10, too. Then CGo will finally be usable outside a single package without those overlapping autogenerated symbols...

UUIDs are one of those useless things standards people create so they can plop it in other standards. They don't, have never and can never solve a real problem, only hypothetical meta problems. That Go team probably sees UUID v7 and LOL'd their underpants off, you couldn't get it right the first 6 times? GTFO

The UUID stdlib debate reveals a deeper tension in API design: when does standardization help vs hurt?

UUIDs won because they're "good enough" - collision-resistant without coordination. But v7's timestamp ordering breaks that independence by leaking information. Now you need to reason about clock sync, monotonicity, privacy.

For distributed systems, I increasingly see folks moving to: use v7 internally (btree efficiency matters), expose v4 externally (don't leak creation order to clients). Add a mapping layer at the API boundary.

The real lesson: IDs are part of your API contract. If clients can infer system behavior from ID structure (request rate, shard assignment, rollout timing), that's signal you may not want to transmit. Standards help, but context still matters.