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

191–200 of 260 posts

Re: UUID package coming to Go standard library

#191

Post by eureka7 »

8organicbits wrote: post #159
jodleif wrote: post #115

Earlier quoted context omitted.

Deterministic uuids is a very standard usecase

You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?

I remember using them in a massive SQL query that needed to generate a GIS data set from multiple tables with an ungodly amount of JOINs and sub-queries to achieve ID stability. Don't ask :p

For those ~~curious~~ worried, no, this was not a security sensitive context.

Re: UUID package coming to Go standard library

#192

Post by intelVISA »

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.

Vibe endian

Re: UUID package coming to Go standard library

#193

Post by xerox13ster »

UqWBcuFx6NV4r wrote: post #157
gzread wrote: post #130

Earlier quoted context omitted.

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.

Ah, yes. LLM-assisted development. That thing that is not at all changing, that thing that different people aren’t doing differently, and that thing that some people aren’t definitely way better at than others. I swear that some supposedly “smart” people on this website throw their ability to think critically out the window when they want to weigh in on the AI culture war. B-but the study! I can way with certainty th…

Nobody is interested in your piece of anecdata and asserting that something has gotten better without doing any studies on it, is the exact opposite of critical thinking.

You are displaying the exact same thing that you were complaining about.

Re: UUID package coming to Go standard library

#194

Post by TomatoCo »

efilife wrote: post #169
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…

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

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.

Re: UUID package coming to Go standard library

#195

Post by pphysch »

wredcoll wrote: post #170
gzread wrote: post #168

Earlier quoted context omitted.

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?

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

Re: UUID package coming to Go standard library

#196

Post by grey-area »

knorker wrote: post #189
grey-area wrote: post #160

Earlier quoted context omitted.

I know, I recently upgraded and skipped several releases without any issues with some large codebases. The compatability guarantee is a massive win, so exciting to have a boring language to build on that doesn’t change much but just gradually gets better.

Really? My experience is that of C, C++, Go, Python, and Rust, Go BY FAR breaks code most often. (except the Python 2->3 change) Sure, most of that is not the compiler or standard library, but dependencies. But I'm not talking random opensource library (I can't blame the core for that), but things like protobuf breaking EVERY TIME. Or x/net, x/crypto, or whatever. But also yes, from random dependencies. It seems that…

The stdlib has been very very stable since the first release - I still use some code from Go 1.0 days which has not evolved much.

The x/ packages are more unstable yes, that's why they're outside stdlib, though I haven't personally noticed any breakage and have never been bitten by this. What breakage did you see?

I think protobuf is notorious for breaking (but more from user changes). I don't use it I'm afraid so have no opinion on that, though it has gone through some major revisions so perhaps that's what you mean?

I don't tend to use much third party code apart from the standard library and some x libraries (most libraries are internal to the org), I'm sure if you do have a lot of external dependencies you might have a different experience.

Re: UUID package coming to Go standard library

#197

Post by 8organicbits »

pclmulqdq wrote: post #187
8organicbits wrote: post #150

Earlier quoted context omitted.

No, UUIDv8 offers 122 bits for vendor specific or experimental use cases. If you fill those bits randomly, you get the same amount of randomness as a v4. The spec is explicit that it does not replace v4 for random data use case. > To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data. https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2

Yes, vendor-specific data can be 100% random.

It can be, but you should prefer UUIDv4 if you do that. One problem is that UUIDv8 does not promise uniqueness.

> UUIDv8's uniqueness will be implementation specific and MUST NOT be assumed.

Here's a spec compliant UUIDv8 implementation I made that doesn't produce unique IDs: https://github.com/robalexdev/uuidv8-xkcd-221

So, given a spec-compliant UUIDv4 you can assume it is unique, but you'd need out-of-band information to make the same assumption about a UUIDv8.

I wrote much more in a blog post: https://alexsci.com/blog/uuid-oops/

Re: UUID package coming to Go standard library

#198

Post by foresto »

therealdrag0 wrote: post #3

Golang lack of support for basic stuff like this is quite annoying.

What stuff do you have in mind?

I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging.

To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in.

I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?

Re: UUID package coming to Go standard library

#199

Post by zadikian »

8organicbits wrote: post #159
jodleif wrote: post #115

Earlier quoted context omitted.

Deterministic uuids is a very standard usecase

You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?

Common one is if you want two structs deemed "equivalent" based on a few fields to get the same ID, and you're only concerned about accidental collision. There are valid use cases for that, but I've also seen it misused often.

v7 rough ordering also helps as a PK in certain sharded DBs, while others want random, or nonsharded ones usually just serial int.

Re: UUID package coming to Go standard library

#200

Post by foresto »

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…

> Deterministic randomization is a thing if you don't want the numbers to count sequentially.

What are your favorite ways to approach this?

I think a maximal period linear feedback shift register might fit well.

Post reply on HN