UUID package coming to Go standard library • Hacker News Board

Re: UUID package coming to Go standard library

#151

Post by gzread » Sat, Mar 07, 2026, 1:07 PM UTC

da_chicken wrote: post #149

gzread wrote: post #128

Earlier quoted context omitted.

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.

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.

Re: UUID package coming to Go standard library

#152

Post by LtWorf » Sat, Mar 07, 2026, 1:07 PM UTC

sethammons wrote: post #103

LtWorf wrote: post #91

Earlier quoted context omitted.

Open the python documentation if you're curious of why people are downvoting you.

I don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.

Honestly, I don't understand what you wrote so I cannot reply.

Re: UUID package coming to Go standard library

#153

Post by LtWorf » Sat, Mar 07, 2026, 1:07 PM UTC

Hendrikto wrote: post #118

LtWorf wrote: post #96

Earlier quoted context omitted.

Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons. For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the…

I think the downvotes are because you did not answer the question you replied to, and instead gave a pretty unrelated rant.

I'm explaining that yes, code does break every new python version? Mostly because they touch the stdlib instead of just leaving it be.

Re: UUID package coming to Go standard library

#154

Post by [deleted] » Sat, Mar 07, 2026, 1:07 PM UTC

sethammons wrote: post #103

LtWorf wrote: post #91

Earlier quoted context omitted.

Open the python documentation if you're curious of why people are downvoting you.

I don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.

[deleted]

Re: UUID package coming to Go standard library

#155

Post by isbvhodnvemrwvn » Sat, Mar 07, 2026, 1:09 PM UTC

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 had enough fun with 2 to 3 transition I think.

Re: UUID package coming to Go standard library

#156

Post by teeray » Sat, Mar 07, 2026, 1:09 PM UTC

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 looking at all the hex now “it’s the one ending in ‘4ab’”.

Re: UUID package coming to Go standard library

#157

Post by UqWBcuFx6NV4r » Sat, Mar 07, 2026, 1:17 PM UTC

gzread wrote: post #130

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.

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 that: 1. LLM-assisted development has gotten significantly, materially better in the past 12 months.

2. I would be incredibly skeptical of any study that’s been designed, executed, analysed, written about, published, snd talked about here, within that period of time.

This is the equivalent of a news headline stating with “science says…”.

Re: UUID package coming to Go standard library

#158

Post by UqWBcuFx6NV4r » Sat, Mar 07, 2026, 1:19 PM UTC

koakuma-chan wrote: post #70

porridgeraisin wrote: post #60

Earlier quoted context omitted.

Yep. Especially for tests with mock data covering all sorts of extreme edge cases.

Don't use AI for that, it doesn't know what your real data looks like.

lol. okay. neither do you.

Re: UUID package coming to Go standard library

#159

Post by 8organicbits » Sat, Mar 07, 2026, 1:20 PM UTC

jodleif wrote: post #115

zadikian wrote: post #89

Earlier quoted context omitted.

Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering

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?

Re: UUID package coming to Go standard library

#160

Post by grey-area » Sat, Mar 07, 2026, 1:30 PM UTC

KingOfCoders wrote: post #69

One thing I love about Go, not fancy-latest-hype features, until the language collapses or every upgrade becomes a nightmare, just adding useful stuff and getting out of the way.

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.