Hacker News

I think "outdated" was a poor choice of words. It is a failure to meet application requirements, which has more to do with design than age. Every standardized UUID is expressly prohibited in some application contexts due to material deficiencies, including v4. That includes newer standards like v7 and v8.

In practice, most orgs with sufficiently large and complex data models use the term "UUID" to mean a pure 128-bit value that makes no reference to the UUID standard. It is not difficult to find yourself with a set of application requirements that cannot be satisfied with a standardized UUID.

The sophistication of our use case scenarios for UUIDs exceeds their original design assumptions. They don't readily support every operation you might want to do on a UUID.

Yeah, I thought it was a strange comment, too. v7 is great when you explicitly need monotonicity, but encoded timestamps can expose information about your system. v4 is still very valid.

Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering

If you want 128 bits of randomness why not use 128 bits of randomness? A random UUID presupposes the random number has to fit in UUID format.

Have you considered using two uuids for more randomness

Really? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).

I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.

I'm seeing deep technical stuff after months, so I'm happy!

It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.

Its a small tech bit but a big architecture / management decision.

Basically, who runs golang?

The perfectionists are correct, UUIDs are awful and if there's a pile of standards that all have small problems the best thing you can do is make a totally new standard to add to the already too long list.

The in-the-trenches system software devs want this BAD. Check out https://en.wikipedia.org/wiki/Universally_unique_identifier#... They want a library that flawlessly interops with everything on that list, ideally. Something you can trust and will not deprecate a function you need for live code and it just works. I admit a certain affinity to this perspective.

The cryptobros want to wait, there is some temporary current turmoil in UUID land. Not like "drama" but things are in flux and it would be horrible for golang to be stuck permanently supporting forever some interim thing that officially gets dropped (or worse, under scrutiny has a security hole or something, but for reverse compatibility with older/present golang would need permanent-ish reverse compatibility) Can't we just wait until 2027 or so? This is not the ideal time to set UUID policy in concrete. Just wait a couple more months or a year or two? https://datatracker.ietf.org/doc/html/rfc9562

I think I covered the three groups that are fighting pretty accurately and at least semi fairly, I did make fun of the perfectionists a little but cut me a break everyone makes fun of those guys.

So, yeah, a "small technical bit" but its actually a super huge architectural / leadership / management decision.

I hope they get it correct, I love golang and have a side thing with tinygo. If you're doing something with microcontrollers that doesn't use networking and you're not locked in to a framework/rtos, just use tinygo its SO cool. Its just fun. I with tinygo had any or decent networking. Why would I need zephyr if I have go routines? Hmm.

I've been around the block a few times with UUID-alike situations and the worst thing they could decide is to swing to an extreme. They'll probably be OK this is not golangs first time around the block either.

It'll probably be OK. I hope.

Here we see Go haters in their natural habitat, the HN comment section.

Watch as they stand at the watering hole, bored and listless. A sad look on their faces, knowing that now that Go has generics, all their joy has left their life. Like the dog that caught his tail, they are confused.

One looks at his friends as if to say, "Now what?"

Suddenly there is a noise.

All heads turn as they see the HN post about UUIDs.

One of the members pounces on it. "Why debate this when the entire industry is collapsing?"

No reply. Silence.

His peers give a half-hearted smile, as if to say, "Thanks for trying" but the truth is apparent. The joy of hating on programming languages is nil when AI is the only thing looking at code any more.

The Go hater returns to the waterhole. Defeated.

I know, I recently upgraded and skipped several releases without any issues with some large codebases.

The compatability guarantee is a massive win, so exciting to have a boring language to build on that doesn’t change much but just gradually gets better.

I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.

While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194

The proposal is 3 years old

At a prior job, there was an internal project code system for tracking billable hours or people assignment kind of thing. Everyone knew the codes of their projects. It was a six digit code, two letters and then four numbers: giving you some ~7 million point space. Company was ~100 years old and only had some 15k codes recorded in all history. The list of codes was manually updated once a quarter by an admin who might add another ten at a time.

Some chuckle head decided to replace the system with UUIDs. Now, they are no longer human memorable/readable/writable on paper/anything useful. Even better, they must have used some home grown implementation, because the codes were weirdly sequential. If you ever had to look at a dump of codes, the ids are almost identical minus a digit somewhere in the middle.

Destructive change that ruined a perfectly functional system.

People should really just use integers.

It's funny how fast it is to just implement a counter and how much people rely on UUIDs to avoid it. If you already use postgres somewhere, just create a "counter" table for your namespace. You can easily count 10K-100k values per second or faster, with room to grow if you outscale that.

What do you get? The most efficient, compressible little integers you could ever want. You unlock data structures like roaring bitmaps/ treemaps. You cut memory to 25% depending on your cardinality (ie: you can use u16 or u32 in memory sometimes). You get insane compression benefits where you can get rows of these integers to take a few bits of data each after compression. You get faster hashmap lookups. It's just insane how this compounds into crazy downstream wins.

It is absolutely insane how little cost it is to do this and how many optimizations you unlock. But people somehow think that id generation will be their bottleneck, or maybe it's just easier to avoid a DB sometimes, or whatever, and so we see UUIDs everywhere. Although, agreed that most of the time you can just generate the unique id for data yourself.

In fairness, UUID is easier, but damn it wrecks performance.

I just wish there was some human element to them so they were easier to talk about. Something like:

BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH

CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO

“Which row was it, ‘basketball fish’ or ‘cake potato’?

Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looking at all the hex now “it’s the one ending in ‘4ab’”.

> Deterministic randomization is a thing if you don't want the numbers to count sequentially.

What are your favorite ways to approach this?

I think a maximal period linear feedback shift register might fit well.

It's currently listed as a 'Likely accept' https://github.com/orgs/golang/projects/17/views/1

Generally means it'll be going in unless something new comes up which alters people's thinking.

Yes

What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.

the idea of what 'batteries included' means has changed a lot in the past twenty years, and like most Go quirks , probably Google just didn't need <missing-things>.

UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.

What stuff do you have in mind?

I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging.

To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in.

I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?

Go has one of the best stdlibs of any language. I'd go as far and say it's the #1 language where the stdlib is the most used for day to day programming. cut the bullshit

It makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons

What other basic stuff are you thinking of?

Now do Javascript.

https://github.com/rs/xid

Others agree. Check out uuidv47

https://github.com/stateless-me/uuidv47

If privacy is the main concern (as it is in most usage of UUIDs) you could just encrypt the integer primary key instead with something like feistel and avoid the performance problems of UUIDs while still having opaque public identifiers.

From nbio's README:

  For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues.

  gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled.
  [...]
  gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services.

However, the net/http package is a different story. It indeed isn't very performant, though one should be careful to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers.

A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make.

[1]: https://pkg.go.dev/github.com/valyala/fasthttp

[2]: https://pkg.go.dev/github.com/gofiber/fiber/v3

It’s kind of ridiculous to argue against UUID being part of the standard package for a language largely aimed at servers. At that point why even have any crypto functions or any of the bigger stuff it already has if the argument is 3rd party libs are enough?

https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email

Basically one guy having a fit when people disagreed with him.

Welcome to literally any Go thread.

UUIDs are recognizable, have a version field, can be sorted in the case of UUIDv7, a standardized format means easy interoperability (eg, encoding, validation, serialization etc), and databases can optimize storage and efficiency when using a native UUID type.

If just using random bytes, you still need to make decisions about how to serialize, put it in a URL, logging etc so you’re basically just inventing you’re own format anyway for a problem that’s already solved.

Why the hate though? Is someone forcing you to use them against your will? If you need 128 bits of crypto.Rand() for your usecase, you can just use that right?

I treat UUIDv4s as 128 random bits and it triggers ppl.

they should be prefixed with something human readable so you can tell a service bot api key from a human developer api key or whatever.

I hate UUIDv4, don't care about the rest. UUIDv4 is just random bytes with hyphens inserted in random places and some bytes reserved to indicate that this is in fact a UUID. This is wasteful and stupid

UUIDs aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life.

One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.

It's an open Github issues thread. What do you expect?

Which is why I changed from being on Gonuts during pre-1.0 days to only touch Go if I really have to.

However I would still advocate for it over C in scenarios easily covered by TinyGo and TamaGo.

I mean that's pretty common in most OSS projects just because you have free entry to the debate.

If you want to see go-uniquie highschool debate club, look at Go team attitude to fixing logging, where community proposed multiple ways of solving it, Go team rejected all of them and then made massive navel-gazing post that could be summed up "well, there is multiple proposals THAT MEANS PEOPLE ARE UNSURE ON THE ISSUE so we won't do shit"

...then removed every question related to go logging (that were common in previous ones) in their yearly survey

It's called bikeshedding. It's highly annoying, but unfortunately every public mailing list or tracker is prone to it.

The maintainers did the right thing by just saying "no."