Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUID package coming to Go standard library

github.com

Post reply on HN
Print view View original

161–170 of 260 posts

Re: UUID package coming to Go standard library

#161

Post by tgv »

teeray wrote: post #156
rkagerer wrote: post #121

That's great, but I abhor UUID's. I see them crop up everywhere. IMO, they are decidedly human-unfriendly - particularly to programmers and database admins trying to debug issues. Too many digits to deal with, and they suck up too much column width in query results, spreadsheets, reports, etc. I'm not saying they don't have a place (e.g. when you have a genuine need to generate unique identifiers across completely di…

I just wish there was some human element to them so they were easier to talk about. Something like: BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO “Which row was it, ‘basketball fish’ or ‘cake potato’? Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looki…

There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway.

But for exposed values (document ids, customer ids, that kind of thing), it can be awkward if a patient's id is suddenly "CRANKY-...-FART".

Re: UUID package coming to Go standard library

#163

Post by 0x696C6961 »

stavros wrote: post #98
0x696C6961 wrote: post #51

Earlier quoted context omitted.

Man... I spent the last 6 months writing code using voice chat with multiple concurrent Claude code agents using an orchestration system because I felt like that was the new required skill set. In the past few weeks I've started opening neovim again and just writing code. It's still 50/50 with a Claude code instance, but fuck I don't feel a big productivity difference.

Really? The past two weeks I've been writing code with AI and feel a massive productivity difference, I ended up with 22k loc, which is probably around as many I'd have manually written for the featureset at hand, except it would have taken me months.

My work involves fixing/adding stuff in legacy systems. Most of the solutions AI comes up with are horrible. I've reverted back to putting problems on my whiteboard and just letting it percolate. I still let AI write most of the code once I know what I want. But I've stopped delegating any decision making to it.

Re: UUID package coming to Go standard library

#164

Post by da_chicken »

bootsmann wrote: post #105
matja wrote: post #81

> UUID versions 1, 2, 3, 4, 5 are already outdated. Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues. Edit: Context links for reference, these recommend UUIDv4: https://www.cockroachlabs.com/docs/stable/uuid https://docs.cloud.google.com…

Really? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).

It's memory and disk paging both.

There's also a hot spot problem with databases. That's the performance problem with autoincrement integers. If you are always writing to the same page on disk, then every write has to lock the same page.

Uuidv7 is a trade off between a messy b-tree (page splits) and a write page hot spot (latch contention). It's always on the right side of the b-tree, but it's spread out more to avoid hot spots.

That still doesn't mean you should always use v7. It does reversibly encode a timestamp, and it could be used to determine the rate that ids are generated (analogous to the German tank problem). If the uuidv7 is monotonic, then it's worse for this issue.

Re: UUID package coming to Go standard library

#165

Post by stavros »

0x696C6961 wrote: post #163
stavros wrote: post #98

Earlier quoted context omitted.

Really? The past two weeks I've been writing code with AI and feel a massive productivity difference, I ended up with 22k loc, which is probably around as many I'd have manually written for the featureset at hand, except it would have taken me months.

My work involves fixing/adding stuff in legacy systems. Most of the solutions AI comes up with are horrible. I've reverted back to putting problems on my whiteboard and just letting it percolate. I still let AI write most of the code once I know what I want. But I've stopped delegating any decision making to it.

Ah, yeah, I can see that. It's not as good with legacy systems, I've found.

Re: UUID package coming to Go standard library

#166

Post by da_chicken »

gzread wrote: post #151
da_chicken wrote: post #149

Earlier quoted context omitted.

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.

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

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.

Re: UUID package coming to Go standard library

#168

Post by gzread »

da_chicken wrote: post #166
gzread wrote: post #151

Earlier quoted context omitted.

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

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 deseri…

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.

Re: UUID package coming to Go standard library

#169

Post by efilife »

da_chicken wrote: post #166
gzread wrote: post #151

Earlier quoted context omitted.

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

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 deseri…

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

Re: UUID package coming to Go standard library

#170

Post by wredcoll »

gzread wrote: post #168
da_chicken wrote: post #166

Earlier quoted context omitted.

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 deseri…

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.

What do they look like when I put it in a url?
Post reply on HN