soypat

UUID package coming to Go standard library

https://github.com/golang/go/issues/62026

proposal: uuid: add API to generate and parse UUID · Issue #62026 · golang/go

I would like to suggest the addition to the standard library of a package to generate and parse UUID identifiers, specifically versions 3, 4 and 5. The main reason I see to include it is that the m...

GitHub
Mar 7 at 2:03amWeb
Show threadtherealdrag0Mar 7
Golang lack of support for basic stuff like this is quite annoying.
Show threadserfMar 7
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 <missing-things>.
Show threadtptacekMar 7
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.
Show threadtptacekMar 7
What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.
Show threadwaynesonfireMar 7
what a bunch of drama in the comments.
Show threadazinman2Mar 7
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?
Show threadtptacekMar 7
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).
Show threadtptacekMar 7
https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
The Bikeshed email — PHKs Bikeshed

Show threadcookiengineerMar 7

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 languages for interoperability so it makes sense to have that in the standard language.

Anyways, I'm just happy we'll get generic methods after 10 years of debates, I suppose. Maybe we'll get an export keyword before another 10, too. Then CGo will finally be usable outside a single package without those overlapping autogenerated symbols...

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