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

211–220 of 260 posts

Re: UUID package coming to Go standard library

#211

Post by 8organicbits »

zadikian wrote: post #199
8organicbits wrote: post #159

Earlier quoted context omitted.

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.

Have you seen UUIDv3/v5 used there though? I've seen lots of md5 historically and sha variants recently, but not the UUID approach.

Re: UUID package coming to Go standard library

#212

Post by [deleted] »

10000truths wrote: post #175
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…

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.

[deleted]

Re: UUID package coming to Go standard library

#213

Post by bastawhiz »

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

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

Re: UUID package coming to Go standard library

#214

Post by knorker »

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

Earlier quoted context omitted.

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

Well, for C++ the backwards compatability is even better. Unless you're using `gets()` or `auto_ptr`, old C++ code either just continue to compile perfectly, or was always broken.

Sure, the Go standard library is in some sense bigger, so it's nice of them to not break that. But short of a Python2->3 or Perl5->6 migration, isn't that just table stakes for a language?

The only good thing about Go is that its standard library has enough coverage to do a reasonable number of things. The only good thing. But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly.

> though [protobuf] has gone through some major revisions so perhaps that's what you mean?

No, it seems it's broken way more often than that, requiring manual changes.

Re: UUID package coming to Go standard library

#215

Post by fredoralive »

0x696C6961 wrote: post #38
jen20 wrote: post #29

Earlier quoted context omitted.

Like Python though, while the batteries are included, many of them are dead.

It begs the question, why don't these languages put out a v2 stdlib?

Python has some work to trim bits of it's built in libraries, see for example https://peps.python.org/pep-0594/ and https://docs.python.org/3/deprecations/index.html .

Re: UUID package coming to Go standard library

#216

Post by herewulf »

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…

Isn't the x for experimental and therefore breaking API changes are expected?

Re: UUID package coming to Go standard library

#217

Post by sourcegrift »

vzaliva wrote: post #26

A slow day in Go-news land? :) It is heathwarming to see such mundane small tech bit making front page of HN when elsewhere is is debated whether programming as profession is dead or more broadly if AI will be enslaving humanity in the next decade. :)

I'm seeing deep technical stuff after months, so I'm happy!

Re: UUID package coming to Go standard library

#218

Post by richard_todd »

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

Earlier quoted context omitted.

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.

Well at least for what I do, success depends on having lots of unit tests to lean on, regardless of whether it is new or existing code. AI plus a hallucination-free feedback loop has been a huge productivity boost for me, personally. Plus it’s an incentive to make lots of good tests (which AI is also good at)

Re: UUID package coming to Go standard library

#219

Post by staticassertion »

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…

People should really just use integers.

It's funny how fast it is to just implement a counter and how much people rely on UUIDs to avoid it. If you already use postgres somewhere, just create a "counter" table for your namespace. You can easily count 10K-100k values per second or faster, with room to grow if you outscale that.

What do you get? The most efficient, compressible little integers you could ever want. You unlock data structures like roaring bitmaps/ treemaps. You cut memory to 25% depending on your cardinality (ie: you can use u16 or u32 in memory sometimes). You get insane compression benefits where you can get rows of these integers to take a few bits of data each after compression. You get faster hashmap lookups. It's just insane how this compounds into crazy downstream wins.

It is absolutely insane how little cost it is to do this and how many optimizations you unlock. But people somehow think that id generation will be their bottleneck, or maybe it's just easier to avoid a DB sometimes, or whatever, and so we see UUIDs everywhere. Although, agreed that most of the time you can just generate the unique id for data yourself.

In fairness, UUID is easier, but damn it wrecks performance.

Re: UUID package coming to Go standard library

#220

Post by chuckadams »

sevg wrote: post #41
jeffrallen wrote: post #35

Am I the only one who hates UUIDs and doesn't see the point of them? Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else. Argh.

UUIDs are recognizable, have a version field, can be sorted in the case of UUIDv7, a standardized format means easy interoperability (eg, encoding, validation, serialization etc), and databases can optimize storage and efficiency when using a native UUID type. If just using random bytes, you still need to make decisions about how to serialize, put it in a URL, logging etc so you’re basically just inventing you’re own…

Has anything post-dating the DCE-RPC era ever looked at the version of a UUID?
Post reply on HN