Re:UUID package coming to Go standard library
by vbezhenar on Saturday March 07, 2026 @01:58AM
(#47285175)
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.
[ Parent
| on HN ]
Re:UUID package coming to Go standard library
by danishanish on Saturday March 07, 2026 @02:26AM
(#47285342)
I think it saves labor and eventual bug hunting to include these in a stdlib. We should not be expected to look up the UUIDv4 spec and make sure you’re following it correctly. This feels like exactly what reasonable encapsulation should be.
Re:UUID package coming to Go standard library
by computomatic on Saturday March 07, 2026 @02:30AM
(#47285366)
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.
Re:UUID package coming to Go standard library
by groestl on Saturday March 07, 2026 @04:12AM
(#47285932)
Let's call it a valid UUIDv0 - all bits randomized including the version bits :)
Re:UUID package coming to Go standard library
by rollulus on Saturday March 07, 2026 @02:40AM
(#47285408)
Well that depends on your luck, it could be a valid one about 1/16th of the time.
Re:UUID package coming to Go standard library
by jasomill on Saturday March 07, 2026 @05:47AM
(#47286405)
1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble.
The fact that we're discussing this at all is a reasonable argument for using a library function.
Re:UUID package coming to Go standard library
by rollulus on Saturday March 07, 2026 @11:17AM
(#47288935)
Nice, thanks and I agree.
Re:UUID package coming to Go standard library
by 3eb7988a1663 on Saturday March 07, 2026 @11:19AM
(#47288954)
While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
Re:UUID package coming to Go standard library
by efilife on Sunday March 08, 2026 @08:01AM
(#47296646)
What do you mean? Are you talking about validation of UUIDs?
Re:UUID package coming to Go standard library
by 3eb7988a1663 on Sunday March 08, 2026 @12:06PM
(#47298407)
If you generate random bytes, which are unlikely to conform to the UUIDv4 spec, my guess is that most libraries will silently accept the id. That is, generating random bytes, will probably work just work.
Re:UUID package coming to Go standard library
by efilife on Sunday March 08, 2026 @12:39PM
(#47298692)
But what libraries are you talking about? What is their purpose?
Re:UUID package coming to Go standard library
by koakuma-chan on Saturday March 07, 2026 @02:50AM
(#47285457)
What if I generate 16 random bytes and use that as id?
Re:UUID package coming to Go standard library
by usrnm on Saturday March 07, 2026 @03:29AM
(#47285704)
No problem, just don't call it UUID
Re:UUID package coming to Go standard library
by vbezhenar on Saturday March 07, 2026 @06:24AM
(#47286632)
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
by Razengan on Saturday March 07, 2026 @05:08AM
(#47286203)
You can say this for everything that has built-in support.
Re:UUID package coming to Go standard library
by vbezhenar on Saturday March 07, 2026 @06:23AM
(#47286626)
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
by 8organicbits on Saturday March 07, 2026 @07:28AM
(#47287050)
I had a similar thought a while back. Looking at the code for existing UUID projects, issues they fixed, and in some cases the CVEs, is a good way to form a different opinion.