[da_chicken]

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.

[gzread]

byte[16] is well supported by most languages and storage systems.

[da_chicken]

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.

[10000truths]

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.

[da_chicken]

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.

[jkrejcha]

> Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG?

There's nothing about UUIDs that need to make them cryptographically secure. Many programming language libraries don't (and some explicitly recommend against using them if you need cryptographically strong randomness).

[foxglacier]

Not for security but to make sure you don't accidentally reuse the same seed. I've done that before when the PRNG seed was the time the application started and it turns out you can run multiple instances at the same time.

[gzread]

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.

[wredcoll]

What do they look like when I put it in a url?

[pphysch]

Use whatever encoding you want? Base64 is probably one of the most practical, but you're not obligated to use that.

[bastawhiz]

UUIDs don't use base64

[bastawhiz]

> There's no serialization.

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

[intelVISA]

Vibe endian

[da_chicken]

Schrodinger's complement

[efilife]

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

[bastawhiz]

> 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.

[TomatoCo]

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.

[hamburglar]

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.

[zadikian]

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)