Live data from Hacker News

UUID package coming to Go standard library

github.com

121–130 of 260 posts

Re: UUID package coming to Go standard library

#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 disconnected locations, and the id's will generally never need to be dealt with by a human). But in practice they've been abused to do everything under the sun (filenames, URL links, user id's, transaction numbers, database primary keys, etc). I almost want to start a website with a gallery of all the examples where they've been unsuitably shoehorned in when just a little more consideration would have produced something more humane.

For most common purposes, a conventional, centralized dispenser is better. Akin to the Take-A-Number reels you see at the deli. Deterministic randomization is a thing if you don't want the numbers to count sequentially. Prefixes, or sharding the ID space, is also a thing, if you need uniqueness across different latency boundaries (like disparate datacenters or siloed servers).

I've lost count of how many times I've seen a UUID generated when what the designer really should have done is just grab the primary key (or when that's awkward, the result of a GetNextId stored procedure) from their database.

Re: UUID package coming to Go standard library

#122

Earlier quoted context omitted.

UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.

You can say this for everything that has built-in support.

Some things are actually hard to implement. I'd spent a lot of time trying to implement concurrent hashmap, for example. UUID is not one of these things.

Re: UUID package coming to Go standard library

#123

Earlier quoted context omitted.

UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.

16 random bytes is not a valid UUIDv4. I don’t think it needs to be in the standard library, but implementing the spec yourself is also not the right choice for 99% of cases.

I didn't say about 16 random bytes. But you're almost there. You generate 16 random bytes and perform few bitwise operations to set version and variant bits correctly.

Not that it matters. I don't even think that there's a single piece of software in the world which would actually care about these bits rather than treating the whole byte array as opaque thing.

Re: UUID package coming to Go standard library

#124

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…

[deleted]

Re: UUID package coming to Go standard library

#125
Is there a way to have benefits of both? Version 7 for better database clustering. And version 4 for complete randomness? So users can not inference nothing from the id? I have an idea: Use version 7 internally, then scramble it before sending to the user. Scrambling could be done by the database or by the server application. It could be as simple as XOR with some 128bit constant, or as resilient as AES encryption. Of course you also need to do unscrambling of IDs coming from users.

Re: UUID package coming to Go standard library

#126

Is there a way to have benefits of both? Version 7 for better database clustering. And version 4 for complete randomness? So users can not inference nothing from the id? I have an idea: Use version 7 internally, then scramble it before sending to the user. Scrambling could be done by the database or by the server application. It could be as simple as XOR with some 128bit constant, or as resilient as AES encryption. O…

If privacy is the main concern (as it is in most usage of UUIDs) you could just encrypt the integer primary key instead with something like feistel and avoid the performance problems of UUIDs while still having opaque public identifiers.

Re: UUID package coming to Go standard library

#127
post #116

Earlier quoted context omitted.

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

https://www.thenile.dev/blog/uuidv7#why-uuidv7 has some details: " UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for th…

In more practical terms:-

1. Users - your users table may not benefit by being ordered by created_at ( or uuid7 ) index because whether or not you need to query that data is tied to the users activity rather than when they first on-boarded.

2 Orders - The majority of your queries on recent orders or historical reporting type query which should benefit for a created_at ( or uuidv7 ) index.

Obviously the argument is then you're leaking data in the key, but my personal take is this is over stated. You might not want to tell people how old a User is, but you're pretty much always going to tell them how old an Order is.

Re: UUID package coming to Go standard library

#128
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…

If you want 128 bits of randomness why not use 128 bits of randomness? A random UUID presupposes the random number has to fit in UUID format.

Re: UUID package coming to Go standard library

#129
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…

I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.

Re: UUID package coming to Go standard library

#130

Earlier quoted context omitted.

It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.

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.

Right. If AI actually made you more productive, there would be more good software around, and we wouldn't have the METR study showing it makes you 20% slower.

AI delivers the feeling of productivity and the ability to make endless PoCs. For some tasks it's actually good, of course, but writing high quality software by itself isn't one.

Post reply on HN