Hacker News Reader

Comment by jagrsw | Hacker News Reader

Imagine how many careers have been built on inventing and promoting something, in the end, turned out to be a cleverly encoded output from /dev/urandom.

View on HN

Indeed. Also, add many other unique identifier formats (ULID, nanoid, bson ids ...) — in contrast to compatibility complaints here — and you'll see that people just love tinkering with trivial things (me too).

What was important during the times when we didn't know how to generate random numbers on computers, perhaps shouldn't be as important today?

Immagine a world where every framework / API / database had its own incompatible UUID format. Without a standard specification that's where we would end up. Do you want to live in such a world?

If you treat the uuid as an opaque binary random value (which is how programs -should- treat it) then variances between versions, or custom versions, have no effect.

As long as they gave sufficient randomness etc, from a program perspective they are unique id's.

There are already multiple versions in active use (4, 7 and arguably 8) so you really shouldn't be using the uuid as anything but a long-random-value.

Yes, the database engine may appreciate one version over another for performance reasons, but that's irrelevant to most developers and programs.

Forget universally compatible UID formats. Frameworks, APIs, and databases only need consistency within their own ecosystem.

Want visually recognizable unique identifiers?

  JAGRSW-UID-<192bit-input-from-urandom-encoded-in-base64>

Need to shave off some bytes?

  JUID-<192bit-input-from-urandom-encoded-in-base64>

Same byte size as UUIDs, arguably more "secure." Can I become an ACM Fellow for solving this problem now?

Seriously, these UUID debates are about as sensible as arguing over XML.

Reply on news.ycombinator.com