upvote

points

by gzread12 hours ago |
comments
upvoteby da_chicken11 hours ago|
[-]
122 bits of randomness.

It's the same reason we use UTF-8. It's well supported. UUIDs are well supported by most languages and storage systems. You don't have to worry about endianness or serialization. It's not a thing you have to think about. It's already been solved and optimized.

reply
upvoteby gzread11 hours ago|
parent|
[-]
byte[16] is well supported by most languages and storage systems.
reply
upvoteby da_chicken10 hours ago|
parent|
[-]
Sure.

Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time.

Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deserialize it? Maybe you should use a string representation, since character transmission is a solved problem with UTF-8. OK, so who decides what that canonical representation is? How do we make it recognizable as an ID without looking like something that people should do arithmetic with?

It's not like random IDs were a new idea in 2002.

reply
upvoteby 10000truths9 hours ago|
parent|
next
[-]
None of these are rocket-science problems, they're just standardization issues. You build a library with your generate_id/serialize_id/deserialize_id functions that work with a wrapper type, and tell your devs to use that library. UUID libraries are exactly that, except backed by an RFC.
reply
upvoteby da_chicken5 hours ago|
parent|
next
[-]
Of course they're not rocket science. But, the question here is, "Why don't you use random 16 bytes instead of a UUIDv4?" It's not a question about rocket science. The answer is still, "Because UUIDv4 is still a better way to do it." The UUID standard solves the second and third tier problems and knock-on effects you don't think about until you've run a system for awhile, or until you start adding multiple information systems that need to interact with the same data.

But, using UUIDv4 shouldn't be rocket science, either. UUID support should be built in to a language intended for web applications, database applications, or business applications. That's why you're using Go or C# instead of C. And Go is somewhat focused on micro-service architectures. It's going to need to serialize and deserialize objects regularly.

reply
upvoteby 4 hours ago|
parent|
prev|
[-]
deleted
reply
upvoteby gzread10 hours ago|
parent|
prev|
next
[-]
How's your UUIDv4 generated?

> Are you sure the way you're serializing it is how the remote system will deserialize it?

It's 16 bytes. There's no serialization.

reply
upvoteby wredcoll9 hours ago|
parent|
next
[-]
What do they look like when I put it in a url?
reply
upvoteby 9 hours ago|
parent|
next
[-]
deleted
reply
upvoteby pphysch7 hours ago|
parent|
prev|
[-]
Use whatever encoding you want? Base64 is probably one of the most practical, but you're not obligated to use that.
reply
upvoteby bastawhiz5 hours ago|
parent|
[-]
UUIDs don't use base64
reply
upvoteby bastawhiz5 hours ago|
parent|
prev|
next
[-]
> There's no serialization.

Hex encoding with hyphens in the right spot isn't serialization?

reply
upvoteby 5 hours ago|
parent|
[-]
deleted
reply
upvoteby intelVISA7 hours ago|
parent|
prev|
[-]
Vibe endian
reply
upvoteby da_chicken15 minutes ago|
parent|
[-]
Schrodinger's complement
reply
upvoteby efilife10 hours ago|
parent|
prev|
[-]
You are really making it seem like a huge problem. Generate random bytes, serialize to a string and store in a db. Done

A downvote tells me nothing. Please tell me what I'm missing, maybe I could learn something

reply
upvoteby bastawhiz4 hours ago|
parent|
next
[-]
> serialize to a string and store in a db

Ah, here we are. If it's just bytes, why store it as a string? Sixteen bytes is just a 128-bit integer, don't waste the space. So now the DB needs to know how to convert your string back to an integer. And back to a string when you ask for it.

"Well why not just keep it as an integer?"

Sure, in which base? With leading zeroes as padding?

But now you also need to handle this in JavaScript, where you have to know to deserialize it to a Bigint or Buffer (or Uint8Array).

UUIDs just mean you don't need to do any of this crap yourself. It's already there and it already works. Everything everywhere speaks the same UUIDs.

reply
upvoteby TomatoCo7 hours ago|
parent|
prev|
next
[-]
You have to generate random bytes with sufficient entropy to avoid collisions and you have to have a consistent way to serialize it to a string. There's already a standard for this, it's called UUID.
reply
upvoteby hamburglar2 hours ago|
parent|
prev|
next
[-]
It’s really not that complicated a problem. Don’t worry, you’ll certainly be able to solve all the problems yourself as you encounter them. What you end up with will be functionally equivalent to a proper UUID and will only have cost you man-months of pain, but then you will be able to truly understand the benefit of not spending your effort on easy problems that someone solved before you.
reply
upvoteby zadikian6 hours ago|
parent|
prev|
[-]
It's not a huge problem. Uuid adds convenience over reinventing that wheel everywhere. And some of those wheels would use the wrong random or hash or encoding.

(Downvote wasn't me)

reply