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.
Man... I spent the last 6 months writing code using voice chat with multiple concurrent Claude code agents using an orchestration system because I felt like that was the new required skill set.
In the past few weeks I've started opening neovim again and just writing code. It's still 50/50 with a Claude code instance, but fuck I don't feel a big productivity difference.
I just write my own code and then ask AI to find any issues and correct them if I feel it is good advice. What AI is amazing at is writing most of my test cases. Saves me a lot of time.
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.
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
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:
Any 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.
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.
RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 as a popular example.
The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue.
Maintaince is much more than RFC compliance, although the project hasn't met that bar either.
One thing I love about Go, not fancy-latest-hype features, until the language collapses or every upgrade becomes a nightmare, just adding useful stuff and getting out of the way.
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.
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.
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>.
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.
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.
> 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?
For a short script, the standard "urllib.request" module [0] works pretty well, and is usually my first choice since it's always installed. For a larger program, I'll usually use a third-party module with more features/async support though, but I'll only do this if I'm using other third-party dependencies anyways.
> JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.
I checked the top 10 Go repositories on GitHub [1], and all but 1 of them have 30+ direct dependencies listed in their "go.mod" files (and many more indirect ones). Also, both C and JavaScript are well-known for their terrible standard libraries, yet out of all languages, JavaScript programs tend to use the most dependencies, while C programs tend to use the least. So I don't think that the number of dependencies that an average program in a given language uses says anything about the quality of that language's standard library.
Fair enough, but the quality/breadth of the standard libraries is fairly topic-specific in Go (and all languages, really). There's a reason that you picked networking and crypto for your examples, since the Go standard library is indeed really strong here—I don't even like Go, but if I had to write a program that did lots of cryptography and networking, then Go would probably be my first choice.
But lots of programs (and most of the programs that I write) don't use any cryptography, and only have trivial networking requirements, and outside those areas, I'd argue that the Python standard library [0] has broader coverage, supports more features, and is better documented than the Go standard library [1].
The Go standard library is still pretty great though, and is well ahead of most other languages; I just personally think that it's a little worse than Python's. But if you mostly write networking/crypto code, I can easily see how you'd have the opposite opinion.
Like, at this point, I feel like we share premises. We disagree, but, fine, seems like a reasonable disagreement. A better one than how annoying it is that Golang lacks "basic stuff" like a standard UUID interface.
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.
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!
Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.
Go has one of the best stdlibs of any language. I'd go as far and say it's the #1 language where the stdlib is the most used for day to day programming. cut the bullshit
Every time I've implemented UUID's it's for a database and something like PostgreSQL would handle it. Still glad to see this feature being worked on, I would have utilized a random string generator instead of the full battle tested UUID specification.
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).
Adding UUID to the standard library is defensible for a server-focused language, but making it part of the stdlib binds maintainers to long-term compatibility and support, so the debate should focus on API surface and long term maintenance rather than whether third-party packages exist.
If added, keep the scope small: implement RFC 4122 v4 generation using crypto/rand.Read with correct version and variant bit handling, provide Parse and String, MarshalText and UnmarshalText, JSON Marshal and Unmarshal hooks, and database/sql Scanner and Valuer, and skip v1 MAC and time based generation by default because of privacy and cross-platform headaches.
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...
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.
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.
I hate UUIDv4, don't care about the rest. UUIDv4 is just random bytes with hyphens inserted in random places and some bytes reserved to indicate that this is in fact a UUID. This is wasteful and stupid
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. :)
In the past few weeks I've started opening neovim again and just writing code. It's still 50/50 with a Claude code instance, but fuck I don't feel a big productivity difference.
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/1
Any 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.
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.
The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue.
Maintaince is much more than RFC compliance, although the project hasn't met that bar either.
Generally means it'll be going in unless something new comes up which alters people's thinking.
> 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...
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.
For a short script, the standard "urllib.request" module [0] works pretty well, and is usually my first choice since it's always installed. For a larger program, I'll usually use a third-party module with more features/async support though, but I'll only do this if I'm using other third-party dependencies anyways.
> JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.
I checked the top 10 Go repositories on GitHub [1], and all but 1 of them have 30+ direct dependencies listed in their "go.mod" files (and many more indirect ones). Also, both C and JavaScript are well-known for their terrible standard libraries, yet out of all languages, JavaScript programs tend to use the most dependencies, while C programs tend to use the least. So I don't think that the number of dependencies that an average program in a given language uses says anything about the quality of that language's standard library.
[0]: https://docs.python.org/3/library/urllib.request.html
[1]: https://github.com/trending/go?since=monthly
That's not what happens in Golang.
But lots of programs (and most of the programs that I write) don't use any cryptography, and only have trivial networking requirements, and outside those areas, I'd argue that the Python standard library [0] has broader coverage, supports more features, and is better documented than the Go standard library [1].
The Go standard library is still pretty great though, and is well ahead of most other languages; I just personally think that it's a little worse than Python's. But if you mostly write networking/crypto code, I can easily see how you'd have the opposite opinion.
[0]: https://docs.python.org/3/library/index.html
[1]: https://pkg.go.dev/std
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.
UUIDs rarely get new versions. I don’t think it’d be too much to expect Go to stay relatively current on that.
If added, keep the scope small: implement RFC 4122 v4 generation using crypto/rand.Read with correct version and variant bit handling, provide Parse and String, MarshalText and UnmarshalText, JSON Marshal and Unmarshal hooks, and database/sql Scanner and Valuer, and skip v1 MAC and time based generation by default because of privacy and cross-platform headaches.
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...
However I would still advocate for it over C in scenarios easily covered by TinyGo and TamaGo.
The maintainers did the right thing by just saying "no."
Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else.
Argh.
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.
A uuidv4 is 15.25 bytes of payload encoded in 36 bytes (using standard serialisation), in a format which is not conducive to gui text selection.
You can encode 16 whole bytes in 26 bytes of easily selectable content by using a random source and encoding in base32, or 22 by using base58.
/s
One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.