what a bunch of drama in the comments.
UUID package coming to Go standard library
11–20 of 260 posts
Re: UUID package coming to Go standard library
#12Odd 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.
Re: UUID package coming to Go standard library
#13what 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?
Re: UUID package coming to Go standard library
#14Golang lack of support for basic stuff like this is quite annoying.
Re: UUID package coming to Go standard library
#15Re: UUID package coming to Go standard library
#16Golang lack of support for basic stuff like this is quite annoying.
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.
Re: UUID package coming to Go standard library
#17Odd 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
Re: UUID package coming to Go standard library
#18Odd 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.
Re: UUID package coming to Go standard library
#19Re: UUID package coming to Go standard library
#20Earlier 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?
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 A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.