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

171–180 of 260 posts

Re: UUID package coming to Go standard library

#171

Post by VLM »

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

Its a small tech bit but a big architecture / management decision.

Basically, who runs golang?

The perfectionists are correct, UUIDs are awful and if there's a pile of standards that all have small problems the best thing you can do is make a totally new standard to add to the already too long list.

The in-the-trenches system software devs want this BAD. Check out https://en.wikipedia.org/wiki/Universally_unique_identifier#... They want a library that flawlessly interops with everything on that list, ideally. Something you can trust and will not deprecate a function you need for live code and it just works. I admit a certain affinity to this perspective.

The cryptobros want to wait, there is some temporary current turmoil in UUID land. Not like "drama" but things are in flux and it would be horrible for golang to be stuck permanently supporting forever some interim thing that officially gets dropped (or worse, under scrutiny has a security hole or something, but for reverse compatibility with older/present golang would need permanent-ish reverse compatibility) Can't we just wait until 2027 or so? This is not the ideal time to set UUID policy in concrete. Just wait a couple more months or a year or two? https://datatracker.ietf.org/doc/html/rfc9562

I think I covered the three groups that are fighting pretty accurately and at least semi fairly, I did make fun of the perfectionists a little but cut me a break everyone makes fun of those guys.

So, yeah, a "small technical bit" but its actually a super huge architectural / leadership / management decision.

I hope they get it correct, I love golang and have a side thing with tinygo. If you're doing something with microcontrollers that doesn't use networking and you're not locked in to a framework/rtos, just use tinygo its SO cool. Its just fun. I with tinygo had any or decent networking. Why would I need zephyr if I have go routines? Hmm.

I've been around the block a few times with UUID-alike situations and the worst thing they could decide is to swing to an extreme. They'll probably be OK this is not golangs first time around the block either.

It'll probably be OK. I hope.

Re: UUID package coming to Go standard library

#172

Post by tomwphillips »

teeray wrote: post #156
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 looki…

At $dayJob we use (user facing) IDs like this. Select a prefix then add a sufficient number of random alphanumeric characters for your use case.

Re: UUID package coming to Go standard library

#174

Post by 15155 »

tptacek wrote: post #33
JimDabell wrote: post #23

Earlier quoted context omitted.

Perhaps I’m misunderstanding, but the linked issue seems to address this directly: > Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library. > C#: https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/A…

You're answering the question of "which languages have UUIDs in their standard libraries" (Javascript is not one of them). That's not the question I'm asking. If you wrote a new Python program today that needed to make HTTP requests, would you rely on the stdlib, or would you pull in a dep? In a Java program, if you were encrypting files or blobs, stdlib or dep? Is C# the language that gives the Go stdlib a run for i…

Ruby has SecureRandom.uuid and others

Re: UUID package coming to Go standard library

#175

Post by 10000truths »

da_chicken wrote: post #166
gzread wrote: post #151

Earlier quoted context omitted.

byte[16] is well supported by most languages and storage systems.

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.

Re: UUID package coming to Go standard library

#176

Post by fl0ki »

sethammons wrote: post #144
gzread wrote: post #138

Earlier quoted context omitted.

You mean he could read it or he could write a parser or he could use a dependency?

Use a dependency. It was a wild pattern that still confuses me years later. Literal interview: concurrently hit these endpoints that returns json and sum the total of values returned. Handle any 400 or 500 level http errors. Literal former Googlers and flubbing the interview. They would spend too much time setting up an IDE and project, not be sure how to handle errors, and unable to parse the json. We eventually add…

"Former Googlers" were probably used to using protobuf so they could get from a function call straight out to a struct of the right schema. It's one level of abstraction higher and near-universal in Google, especially in internal-to-internal communication edges.

I don't think it's a strong hiring signal if they weren't already familiar with APIs for (de)serialization in between, because if they're worth anything then they'll just pick that up from documentation and be done with it.

Re: UUID package coming to Go standard library

#177

Post by VLM »

teeray wrote: post #156
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 looki…

There's been a lot of historical work done in the past and I used NIST FIPS181 to implement this.

Note: FIPS181 was intended for passwords and I was using them as handy short human-readable record IDs as per your post. You probably shouldn't use FIPS181 for passwords in 2026 LOL.

Describing FIPS181 as pronounceable is optimistic. However its better than random text wrt human conversations. They start looking like mysterious assembly language mnemonics after awhile.

Re: UUID package coming to Go standard library

#178

Post by a57721 »

sethammons wrote: post #144
gzread wrote: post #138

Earlier quoted context omitted.

You mean he could read it or he could write a parser or he could use a dependency?

Use a dependency. It was a wild pattern that still confuses me years later. Literal interview: concurrently hit these endpoints that returns json and sum the total of values returned. Handle any 400 or 500 level http errors. Literal former Googlers and flubbing the interview. They would spend too much time setting up an IDE and project, not be sure how to handle errors, and unable to parse the json. We eventually add…

You mention it was 8 years ago, at that point a typical Java dev would be already using Spring Boot for requests and deserializing JSON to POJOs (with Jackson under the hood).

Re: UUID package coming to Go standard library

#179

Post by lijok »

matja wrote: 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…

Have you considered using two uuids for more randomness

Re: UUID package coming to Go standard library

#180

Post by 3eb7988a1663 »

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…

At a prior job, there was an internal project code system for tracking billable hours or people assignment kind of thing. Everyone knew the codes of their projects. It was a six digit code, two letters and then four numbers: giving you some ~7 million point space. Company was ~100 years old and only had some 15k codes recorded in all history. The list of codes was manually updated once a quarter by an admin who might add another ten at a time.

Some chuckle head decided to replace the system with UUIDs. Now, they are no longer human memorable/readable/writable on paper/anything useful. Even better, they must have used some home grown implementation, because the codes were weirdly sequential. If you ever had to look at a dump of codes, the ids are almost identical minus a digit somewhere in the middle.

Destructive change that ruined a perfectly functional system.

Post reply on HN