4 ms·

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.

by jagrsw 2y ago

zerodensity 2y ago
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?
- bruce511 2y ago
  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.
- jagrsw 2y ago
  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.
dchest 2y ago
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?

4 ms·

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.

by jagrsw 2y ago

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.

zerodensity 2y ago
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?
- bruce511 2y ago
  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.
- jagrsw 2y ago
  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.
dchest 2y ago
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?