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

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.

I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.

especially when they don't depend on libc.

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

The RFC isn’t changing, is it?

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/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.

Alternative take: don't put draft RFCs into prod

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.

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.

Based on the conversation, is it actually coming?

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 <missing-things>.

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?

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.

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

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.

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!

Like Python though, while the batteries are included, many of them are dead.

It begs the question, why don't these languages put out a v2 stdlib?

Obviously PHP

What other basic stuff are you thinking of?

Now do Javascript.

crypto.randomUUID()?

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?

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.

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.

It would appear that person and OP are one in the same.

Welcome to literally any Go thread.

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.

I treat UUIDv4s as 128 random bits and it triggers ppl.

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

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.