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 .
UUID package coming to Go standard library
31–40 of 260 posts
Re: UUID package coming to Go standard library
#32Earlier 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…
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
#33Earlier 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…
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
#34Earlier 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
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
#35Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else.
Argh.
Re: UUID package coming to Go standard library
#36what a bunch of drama in the comments.
Re: UUID package coming to Go standard library
#37Earlier 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?
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
#38Earlier 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.
Re: UUID package coming to Go standard library
#39Re: UUID package coming to Go standard library
#40Am 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.