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.
replyIf 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.
That the problem is already solved does not mean the solution is good. Or that you can’t solve it better.
replyA uuidv4 is 15.25 bytes of payload encoded in 36 bytes (using standard serialisation), in a format which is not conducive to gui text selection.
You can encode 16 whole bytes in 26 bytes of easily selectable content by using a random source and encoding in base32, or 22 by using base58.
deleted
replyHas anything post-dating the DCE-RPC era ever looked at the version of a UUID?
replyWhy 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?
replyI treat UUIDv4s as 128 random bits and it triggers ppl.
replyIt needs several non-random bits to mark it as a v4 or it's not a uuidv4
replyTo be fair that’s literally just a waste of resources. If you want 128 random bits just get 128 random bits from the underlying source, unless your host langage is amazingly deficient it’s just as easy.
replythey should be prefixed with something human readable so you can tell a service bot api key from a human developer api key or whatever.
replyhahahaha as if humans wouldn't just give their hey to the bot
replyThat misses the point. The point is for easy validation that the key was generated appropriately. Many api keys have a standard prefix for just this reason. It especially helps on documentation where the key name might be confused with the value: "your key starts with hnkey-"
replyI 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
replyIs reserving 6 bits really that bad?
replyYou can use different encodings based on context, just like with a random blob of bytes.
You aren't supposed to store the hyphens, and that's the same for all versions.
replyWhat if I want an ID in the URL? Parse it back and forth? And what if for example, nodejs's UUID api only gives me the string representation of the ID?
replyTo minimize the storage space while having a URL-safe representation, yeah you'd want to serialise/deserialise on the boundary of presenting it to API consumers. I think the same for any ID that has an efficient binary representation as well as needing to represent it in ASCII.
replyUUIDs 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.
replyOne example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.
The global uniqueness of a uuid v4 is the global uniqueness of pulling 122 bits from a source of entropy. Structure has nothing to do with it, and pulling 128 bits from the same source is strictly (if not massively) superior at that.
replyI stand corrected. I was thinking of the sequential nature of uuid 7, or SQL servers sequential id.
reply