Discussion
Search code, repositories, users, issues, pull requests...
kayson: Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.
waynesonfire: what a bunch of drama in the comments.
therealdrag0: Golang lack of support for basic stuff like this is quite annoying.
serf: 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>.
azinman2: 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?
rednafi: Basically one guy having a fit when people disagreed with him.
nwhnwh: https://github.com/rs/xid
tptacek: https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
tptacek: 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.
catlifeonmars: [delayed]
tptacek: 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).
da_chicken: While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194
rafram: The RFC isn’t changing, is it?
harrall: Obviously PHP
fractorial: It would appear that person and OP are one in the same.
0x696C6961: I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.
JimDabell: 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/API/Crypto/rand...> Python: https://docs.python.org/3/library/uuid.html> Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...
vips7L: People are weird. A few days ago someone on /r/Java was arguing that a basic JSON parser shouldn’t be in the standard library.
cookiengineer: 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...
JimDabell: I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities.This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed:https://github.com/stevesimmons/uuid7/issues/1Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running.This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+.A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.
zdw: Now do Javascript.
sheept: crypto.randomUUID()?
pjmlp: Which is why I changed from being on Gonuts during pre-1.0 days to only touch Go if I really have to.However I would still advocate for it over C in scenarios easily covered by TinyGo and TamaGo.
artimaeis: My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
0x696C6961: Alternative take: don't put draft RFCs into prod
vzaliva: 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. :)
JimDabell: It hasn’t been a draft RFC for a couple of years:https://datatracker.ietf.org/doc/rfc9562/The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.
tptacek: 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 its money? I haven't used it much. JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.I asked the question I did upthread because, while there are a lot of colorable arguments about what Go did wrong, a complete and practical standard library where the standard library's functionality is the idiomatic answer to the problems it addresses is one of the things Go happens to do distinctively well. Which makes dunking on it for this UUID thing kind of odd.
throwaway894345: No one is debating whether Go is missing a uuid package from its standard library; the debate is about whether this is indicative of a general trend with the Go standard library (as the gp claimed above).If you’re arguing as the grandparent did that Go regularly omits important packages from its standard library, then it’s not unreasonable to ask you for your idea of an exemplary stdlib.
throwaway894345: Google is the author of the de facto uuid library in Go, google/uuid. I’m very curious what people think is an exemplary “batteries included” stdlib?
ycombinatrix: especially when they don't depend on libc.
jen20: Like Python though, while the batteries are included, many of them are dead.
