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

41–50 of 260 posts

Re: UUID package coming to Go standard library

#41

Post by sevg »

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 format anyway for a problem that’s already solved.

Re: UUID package coming to Go standard library

#42

Post by azinman2 »

tptacek wrote: post #13
azinman2 wrote: post #11

Earlier quoted context omitted.

It’s kind of ridiculous to argue against UUID being part of the standard package for a language largely aimed at servers. At that point why even have any crypto functions or any of the bigger stuff it already has if the argument is 3rd party libs are enough?

UUIDv7 didn't mature until long after the Go standard library was mostly settled. By that point, there was already an idiomatic 3p dep for UUIDs (the Google package), and as you can see from the thread, there were arguments in favor of keeping it 3p (it can be updated on an arbitrary cadence, unlike the stdlib).

They could have implemented the other types of uuid generation, as well as having the standard type. Then evolve.

UUIDs rarely get new versions. I don’t think it’d be too much to expect Go to stay relatively current on that.

Re: UUID package coming to Go standard library

#43

Post by tptacek »

serf wrote: post #4
therealdrag0 wrote: post #3

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

the idea of what 'batteries included' means has changed a lot in the past twenty years, and like most Go quirks , probably Google just didn't need .

Huh? The universal idiomatic answer to "how to use UUIDs in Go programs" for the past decade has been to pull in a Google dep.

Re: UUID package coming to Go standard library

#44

Post by tptacek »

cookiengineer wrote: post #21

Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate. I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languag…

It's an open Github issues thread. What do you expect?

Re: UUID package coming to Go standard library

#45

Post by beart »

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 aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life.

One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.

Re: UUID package coming to Go standard library

#46

Post by masklinn »

beart wrote: post #45
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 aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life. One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.

The global uniqueness of a uuid v4 is the global uniqueness of pulling 122 bits from a source of entropy. Structure has nothing to do with it, and pulling 128 bits from the same source is strictly (if not massively) superior at that.

Re: UUID package coming to Go standard library

#47

Post by fragmede »

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.

they should be prefixed with something human readable so you can tell a service bot api key from a human developer api key or whatever.

Re: UUID package coming to Go standard library

#48

Post by hrmtst93837 »

azinman2 wrote: post #11
waynesonfire wrote: post #5

what a bunch of drama in the comments.

It’s kind of ridiculous to argue against UUID being part of the standard package for a language largely aimed at servers. At that point why even have any crypto functions or any of the bigger stuff it already has if the argument is 3rd party libs are enough?

[flagged]

Re: UUID package coming to Go standard library

#49

Post by serial_dev »

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

It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.

Re: UUID package coming to Go standard library

#50

Post by silisili »

cookiengineer wrote: post #21

Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate. I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languag…

It's called bikeshedding. It's highly annoying, but unfortunately every public mailing list or tracker is prone to it.

The maintainers did the right thing by just saying "no."

Post reply on HN