Live data from Hacker News

UUID package coming to Go standard library

github.com

31–40 of 260 posts

Re: UUID package coming to Go standard library

#31
post #4

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 .

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?

Re: UUID package coming to Go standard library

#32
post #7

Earlier quoted context omitted.

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/A…

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.

Re: UUID package coming to Go standard library

#33
post #7

Earlier quoted context omitted.

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/A…

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.

Re: UUID package coming to Go standard library

#34

Earlier quoted context omitted.

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/steve…

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.

Re: UUID package coming to Go standard library

#37
post #17

Earlier quoted context omitted.

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?

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.

Re: UUID package coming to Go standard library

#38
post #29

Earlier quoted context omitted.

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?

Re: UUID package coming to Go standard library

#40

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.

I treat UUIDv4s as 128 random bits and it triggers ppl.
Post reply on HN