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...

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. :)

I did an analysis of Go dependencies[1] a few weeks ago and google/uuid is the 2nd most used dependency in the open source ecosystem, so its inclusion will be very impactful.

[1]: https://blog.thibaut-rousseau.com/blog/the-most-popular-go-d...

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.

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

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).

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...

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

Argh.