22 ms·

UUID package coming to Go standard library

375 points by soypat 7mo ago

therealdrag0 7mo ago
Golang lack of support for basic stuff like this is quite annoying.
- serf 7mo ago
  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>.
  - throwaway894345 7mo ago
    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?
  - tptacek 7mo ago
    Huh? The universal idiomatic answer to "how to use UUIDs in Go programs" for the past decade has been to pull in a Google dep.
- zdw 7mo ago
  Now do Javascript.
  - sheept 7mo ago
    crypto.randomUUID()?
- tptacek 7mo ago
  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.
  - harrall 7mo ago
    Obviously PHP
  - JimDabell 7mo ago
    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.newguid?view=net-7.0&redirectedfrom=MSDN#System_Guid_NewGuid https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand... > Python: https://docs.python.org/3/library/uuid.html https://docs.python.org/3/library/uuid.html > Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html#method-c-uuid https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...
    - throwaway894345 7mo ago
      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.
      - thayne 7mo ago
        I think the closest thing to an exemplary stdlin is rust's std. I think it strikes a good balance between being too small or too big. Unfortunately, what rust doesn't really have (yet) is a "blessed" set of libraries to supplement the stdlib. The problems with a big "batteries included" standard library like go or python strives for, are that you will inevitably leave things out that at least some people consider "basic", like uuid, and parts of stdlib will probably have lower quality than third party libraries, like pythons urllib or gos log package, and it is constrained by needing to maintain backwards compatibility and being tied to the language's release cycle.
- nwhnwh 7mo ago
  https://github.com/rs/xid https://github.com/rs/xid
- catlifeonmars 7mo ago
  What other basic stuff are you thinking of?
  - patrickmcnamara 7mo ago
    I'd love to see proper WebSocket support, and JWTs.
    - catlifeonmars 7mo ago
      What other languages have web socket support or JWT validation as part of their standard libraries? I don’t disagree with you btw. JWT signing/verification and JWK support is especially something I would prefer had first class implementations. (I’m much less concerned with JWT parsing, which is trivial).
- vbezhenar 7mo ago
  UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.
  - danishanish 7mo ago
    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.
  - computomatic 7mo ago
    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.
    - rollulus 7mo ago
      Well that depends on your luck, it could be a valid one about 1/16th of the time.
      - jasomill 7mo ago
        1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble. The fact that we're discussing this at all is a reasonable argument for using a library function.
        rollulus 7mo ago
        Nice, thanks and I agree.
        3eb7988a1663 7mo ago
        While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
- orangeisthe 7mo ago
  [flagged]
  - LtWorf 7mo ago
    Open the python documentation if you're curious of why people are downvoting you.
    - sethammons 7mo ago
      I don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.
      - LtWorf 7mo ago
        Honestly, I don't understand what you wrote so I cannot reply.
      - deleted 7mo ago
        [deleted]
    - HendrikHensen 7mo ago
      I cannot identify with this at all. We have Python and Go applications in production, and for Go the vibe is mostly "standard library plus a few dependencies" (e.g. SQL driver, opentelemetry) whereas with Python it's mostly "we need a dozen libraries just to get something done". For example Go has production ready HTTP server and client implementations in the standard library. But with Python, you have to use FastAPI or Flask, and requests or httpx. For SQL there's SQLAlchemy I guess and probably some other alternatives (my Python knowledge is not that great), whereas again with Go the abstraction is just in the standard library and you only include the driver for the specific database. We use Renovate to manage dependency upgrades. It runs once a week. Every Python project has a handful or more dependency upgrades waiting every week, primarily due to the huge amount of dependencies and transitive dependencies in each project. The Go projects sometimes have one or two, but most of the time they're silent because there is nothing to upgrade (partly due to just having so few dependencies to begin with).
- p0w3n3d 7mo ago
  It makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons
- foresto 7mo ago
  What stuff do you have in mind? I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging. To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in. I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?
kayson 7mo ago
Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.
- da_chicken 7mo ago
  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 https://github.com/google/uuid/issues/194
  - rafram 7mo ago
    The RFC isn’t changing, is it?
    - JimDabell 7mo ago
      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 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.
      - 7mo ago
waynesonfire 7mo ago
what a bunch of drama in the comments.
- rednafi 7mo ago
  Basically one guy having a fit when people disagreed with him.
  - fractorial 7mo ago
    It would appear that person and OP are one in the same.
    - arccy 7mo ago
      maybe the OP is trying but failing to drum up support for his unergonomic api proposal
    - rednafi 7mo ago
      Damn. I missed that. But yeah OP didn't take it well when people poked hole into his proposed API. But regardless of API ergonomics, I would love to have UUID v4 and v7 in the stdlib.
- tptacek 7mo ago
  https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
- azinman2 7mo ago
  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?
  - tptacek 7mo ago
    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).
cookiengineer 7mo ago
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...
- pjmlp 7mo ago
  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.
- tptacek 7mo ago
  It's an open Github issues thread. What do you expect?
  - cookiengineer 7mo ago
    I guess open debate and productive discussions?
    - tptacek 7mo ago
      You must be new to this.
- silisili 7mo ago
  It's called bikeshedding. It's highly annoying, but unfortunately every public mailing list or tracker is prone to it. The maintainers did the right thing by just saying "no."
- PunchyHamster 7mo ago
vzaliva 7mo ago
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. :)
- deleted 7mo ago
  [deleted]
- serial_dev 7mo ago
  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.
  - 0x696C6961 7mo ago
    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.
    - cwbriscoe 7mo ago
      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.
      - porridgeraisin 7mo ago
        Yep. Especially for tests with mock data covering all sorts of extreme edge cases.
        koakuma-chan 7mo ago
jeffrallen 7mo ago
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.
- whateveracct 7mo ago
  I treat UUIDv4s as 128 random bits and it triggers ppl.
  - masklinn 7mo ago
    To be fair that’s literally just a waste of resources. If you want 128 random bits just get 128 random bits from the underlying source, unless your host langage is amazingly deficient it’s just as easy.
  - gzread 7mo ago
    It needs several non-random bits to mark it as a v4 or it's not a uuidv4
- sevg 7mo ago
  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.
  - masklinn 7mo ago
    That the problem is already solved does not mean the solution is good. Or that you can’t solve it better. 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.
didip 7mo ago
Based on the conversation, is it actually coming?
- 0x696C6961 7mo ago
  Yes
- remus 7mo ago
  It's currently listed as a 'Likely accept' https://github.com/orgs/golang/projects/17/views/1 https://github.com/orgs/golang/projects/17/views/1 Generally means it'll be going in unless something new comes up which alters people's thinking.
kittikitti 7mo ago
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.
KingOfCoders 7mo ago
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.
- grey-area 7mo ago
  I know, I recently upgraded and skipped several releases without any issues with some large codebases. The compatability guarantee is a massive win, so exciting to have a boring language to build on that doesn’t change much but just gradually gets better.
  - knorker 7mo ago
    Really? My experience is that of C, C++, Go, Python, and Rust, Go BY FAR breaks code most often. (except the Python 2->3 change) Sure, most of that is not the compiler or standard library, but dependencies. But I'm not talking random opensource library (I can't blame the core for that), but things like protobuf breaking EVERY TIME. Or x/net, x/crypto, or whatever. But also yes, from random dependencies. It seems that language-culturally, Go authors are fine with breaking changes. Whereas I don't see that with people making Rust crates. And multiple times I've dug out C++ projects that I have not touched in 25 years, and they just work.
    - grey-area 7mo ago
      The stdlib has been very very stable since the first release - I still use some code from Go 1.0 days which has not evolved much. The x/ packages are more unstable yes, that's why they're outside stdlib, though I haven't personally noticed any breakage and have never been bitten by this. What breakage did you see? I think protobuf is notorious for breaking (but more from user changes). I don't use it I'm afraid so have no opinion on that, though it has gone through some major revisions so perhaps that's what you mean? I don't tend to use much third party code apart from the standard library and some x libraries (most libraries are internal to the org), I'm sure if you do have a lot of external dependencies you might have a different experience.
matja 7mo ago
> UUID versions 1, 2, 3, 4, 5 are already outdated. Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues. Edit: Context links for reference, these recommend UUIDv4: https://www.cockroachlabs.com/docs/stable/uuid https://www.cockroachlabs.com/docs/stable/uuid https://docs.cloud.google.com/spanner/docs/schema-design#uuid_primary_key https://docs.cloud.google.com/spanner/docs/schema-design#uui...
- zadikian 7mo ago
  Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering
  - jodleif 7mo ago
    Deterministic uuids is a very standard usecase
    - 8organicbits 7mo ago
      You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?
      - eureka7 7mo ago
        I remember using them in a massive SQL query that needed to generate a GIS data set from multiple tables with an ungodly amount of JOINs and sub-queries to achieve ID stability. Don't ask :p For those ~~curious~~ worried, no, this was not a security sensitive context.
      - zadikian 7mo ago
        Common one is if you want two structs deemed "equivalent" based on a few fields to get the same ID, and you're only concerned about accidental collision. There are valid use cases for that, but I've also seen it misused often. v7 rough ordering also helps as a PK in certain sharded DBs, while others want random, or nonsharded ones usually just serial int.
jillesvangurp 7mo ago
Kotlin also added RFC 9562 (which includes the new UUID versions) support to the standard library in version 2.3 recently. It's a multi platform implementation too so it works on native, wasm, jvm and js. I think it makes a lot of sense to default to that now that the IETF RFC has been out for a few years. So, it makes sense for Go to introduce support for this as well.
knodi 7mo ago
Go is often the best part of my work day.
casey2 7mo ago
[flagged]
rkagerer 7mo ago
That's great, but I abhor UUID's. I see them crop up everywhere. IMO, they are decidedly human-unfriendly - particularly to programmers and database admins trying to debug issues. Too many digits to deal with, and they suck up too much column width in query results, spreadsheets, reports, etc. I'm not saying they don't have a place (e.g. when you have a genuine need to generate unique identifiers across completely disconnected locations, and the id's will generally never need to be dealt with by a human). But in practice they've been abused to do everything under the sun (filenames, URL links, user id's, transaction numbers, database primary keys, etc). I almost want to start a website with a gallery of all the examples where they've been unsuitably shoehorned in when just a little more consideration would have produced something more humane. For most common purposes, a conventional, centralized dispenser is better. Akin to the Take-A-Number reels you see at the deli. Deterministic randomization is a thing if you don't want the numbers to count sequentially. Prefixes, or sharding the ID space, is also a thing, if you need uniqueness across different latency boundaries (like disparate datacenters or siloed servers). I've lost count of how many times I've seen a UUID generated when what the designer really should have done is just grab the primary key (or when that's awkward, the result of a GetNextId stored procedure) from their database.
- deleted 7mo ago
  [deleted]
- teeray 7mo ago
  I just wish there was some human element to them so they were easier to talk about. Something like: BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO “Which row was it, ‘basketball fish’ or ‘cake potato’? Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looking at all the hex now “it’s the one ending in ‘4ab’”.
  - tgv 7mo ago
    There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway. But for exposed values (document ids, customer ids, that kind of thing), it can be awkward if a patient's id is suddenly "CRANKY-...-FART".
MarekKnapek 7mo ago
Is there a way to have benefits of both? Version 7 for better database clustering. And version 4 for complete randomness? So users can not inference nothing from the id? I have an idea: Use version 7 internally, then scramble it before sending to the user. Scrambling could be done by the database or by the server application. It could be as simple as XOR with some 128bit constant, or as resilient as AES encryption. Of course you also need to do unscrambling of IDs coming from users.
- grey-area 7mo ago
  If privacy is the main concern (as it is in most usage of UUIDs) you could just encrypt the integer primary key instead with something like feistel and avoid the performance problems of UUIDs while still having opaque public identifiers.
- 8organicbits 7mo ago
  Others agree. Check out uuidv47 https://github.com/stateless-me/uuidv47 https://github.com/stateless-me/uuidv47
gethly 7mo ago
Seems pointless. Go should focus on refactoring core libraries, especially net and http, for performance because nbio, gnet and others are kicking its ass. And that is sad, as third party libraries should never perform better than standard library. Also swiss tables were great addition to Go's native maps, but then again there are faster libraries that can give you 3x performance(in case of numeric keys).
- kbolino 7mo ago
  From nbio's README: For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues. From gnet's README: gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled. [...] gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services. Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface. However, the net/http package is a different story. It indeed isn't very performant, though one should be careful to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers. A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make. [1]: https://pkg.go.dev/github.com/valyala/fasthttp https://pkg.go.dev/github.com/valyala/fasthttp [2]: https://pkg.go.dev/github.com/gofiber/fiber/v3 https://pkg.go.dev/github.com/gofiber/fiber/v3
  - gethly 7mo ago
    STD is built on goroutines whereas these performance networking libraries are built on a main reactor loop. Hence the need for refactoring, not just tweaking. Something like http/v2 and net/v2. I know gnet had(has?) issues wit implementing tls because how the entire STD is designed to work. At the time, it was a great piece of software, but by now, it is slow and outdated. A lot of progress has been made since in networking, parsing, serialization, atomics and so on.
sieep 7mo ago
Cool! I love go and things like this will keep bringing me back :)
ollybrinkman 7mo ago
[flagged]
malklera 7mo ago
Wonder about the opinion of the maintainers of the Google package. Will they put it on maintenance mode or continue developing it like usual?
thiht 7mo ago
I don’t really care for Go supporting UUID generation, but UUIDs being a type from the stdlib will be invaluable, if they correctly implement the JSON, Text, database/sql and other standard marshallers/unmarshallers. We seriously need a standard UUID type across the ecosystem, and I’m glad it’s coming. I did an analysis of Go dependencies[1] a few weeks ago and google/uuid is the 2nd most used dependency in the open source ecosystem, so its inclusion will be very impactful. [1]: https://blog.thibaut-rousseau.com/blog/the-most-popular-go-dependency-is/ https://blog.thibaut-rousseau.com/blog/the-most-popular-go-d...
- kardianos 7mo ago
  I would say the same for dec128. I would love a standard TYPE for dec128, with maybe zero cost std lib to transform it into a mutable uint128 or a zero cost conversion to struct{uint64,int64).
andrewrozumy 7mo ago
[flagged]

375 points by soypat 7mo ago

therealdrag0 7mo ago

Golang lack of support for basic stuff like this is quite annoying.

serf 7mo ago
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>.
- throwaway894345 7mo ago
  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?
- tptacek 7mo ago
  Huh? The universal idiomatic answer to "how to use UUIDs in Go programs" for the past decade has been to pull in a Google dep.
zdw 7mo ago
Now do Javascript.
- sheept 7mo ago
  crypto.randomUUID()?
tptacek 7mo ago
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.
- harrall 7mo ago
  Obviously PHP
- JimDabell 7mo ago
  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.newguid?view=net-7.0&redirectedfrom=MSDN#System_Guid_NewGuid https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand... > Python: https://docs.python.org/3/library/uuid.html https://docs.python.org/3/library/uuid.html > Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html#method-c-uuid https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...
  - throwaway894345 7mo ago
    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.
    - thayne 7mo ago
      I think the closest thing to an exemplary stdlin is rust's std. I think it strikes a good balance between being too small or too big. Unfortunately, what rust doesn't really have (yet) is a "blessed" set of libraries to supplement the stdlib. The problems with a big "batteries included" standard library like go or python strives for, are that you will inevitably leave things out that at least some people consider "basic", like uuid, and parts of stdlib will probably have lower quality than third party libraries, like pythons urllib or gos log package, and it is constrained by needing to maintain backwards compatibility and being tied to the language's release cycle.
nwhnwh 7mo ago
https://github.com/rs/xid https://github.com/rs/xid
catlifeonmars 7mo ago
What other basic stuff are you thinking of?
- patrickmcnamara 7mo ago
  I'd love to see proper WebSocket support, and JWTs.
  - catlifeonmars 7mo ago
    What other languages have web socket support or JWT validation as part of their standard libraries? I don’t disagree with you btw. JWT signing/verification and JWK support is especially something I would prefer had first class implementations. (I’m much less concerned with JWT parsing, which is trivial).
vbezhenar 7mo ago
UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.
- danishanish 7mo ago
  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.
- computomatic 7mo ago
  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.
  - rollulus 7mo ago
    Well that depends on your luck, it could be a valid one about 1/16th of the time.
    - jasomill 7mo ago
      1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble. The fact that we're discussing this at all is a reasonable argument for using a library function.
      - rollulus 7mo ago
        Nice, thanks and I agree.
      - 3eb7988a1663 7mo ago
        While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
orangeisthe 7mo ago
[flagged]
- LtWorf 7mo ago
  Open the python documentation if you're curious of why people are downvoting you.
  - sethammons 7mo ago
    I don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.
    - LtWorf 7mo ago
      Honestly, I don't understand what you wrote so I cannot reply.
    - deleted 7mo ago
      [deleted]
  - HendrikHensen 7mo ago
    I cannot identify with this at all. We have Python and Go applications in production, and for Go the vibe is mostly "standard library plus a few dependencies" (e.g. SQL driver, opentelemetry) whereas with Python it's mostly "we need a dozen libraries just to get something done". For example Go has production ready HTTP server and client implementations in the standard library. But with Python, you have to use FastAPI or Flask, and requests or httpx. For SQL there's SQLAlchemy I guess and probably some other alternatives (my Python knowledge is not that great), whereas again with Go the abstraction is just in the standard library and you only include the driver for the specific database. We use Renovate to manage dependency upgrades. It runs once a week. Every Python project has a handful or more dependency upgrades waiting every week, primarily due to the huge amount of dependencies and transitive dependencies in each project. The Go projects sometimes have one or two, but most of the time they're silent because there is nothing to upgrade (partly due to just having so few dependencies to begin with).
p0w3n3d 7mo ago
It makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons
foresto 7mo ago
What stuff do you have in mind? I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging. To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in. I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?

kayson 7mo ago

Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.

da_chicken 7mo ago
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 https://github.com/google/uuid/issues/194
- rafram 7mo ago
  The RFC isn’t changing, is it?
  - JimDabell 7mo ago
    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 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.
    - 7mo ago

waynesonfire 7mo ago

what a bunch of drama in the comments.

rednafi 7mo ago
Basically one guy having a fit when people disagreed with him.
- fractorial 7mo ago
  It would appear that person and OP are one in the same.
  - arccy 7mo ago
    maybe the OP is trying but failing to drum up support for his unergonomic api proposal
  - rednafi 7mo ago
    Damn. I missed that. But yeah OP didn't take it well when people poked hole into his proposed API. But regardless of API ergonomics, I would love to have UUID v4 and v7 in the stdlib.
tptacek 7mo ago
https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
azinman2 7mo ago
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?
- tptacek 7mo ago
  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).

cookiengineer 7mo ago

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

pjmlp 7mo ago
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.
tptacek 7mo ago
It's an open Github issues thread. What do you expect?
- cookiengineer 7mo ago
  I guess open debate and productive discussions?
  - tptacek 7mo ago
    You must be new to this.
silisili 7mo ago
It's called bikeshedding. It's highly annoying, but unfortunately every public mailing list or tracker is prone to it. The maintainers did the right thing by just saying "no."
PunchyHamster 7mo ago

vzaliva 7mo ago

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

deleted 7mo ago
[deleted]
serial_dev 7mo ago
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.
- 0x696C6961 7mo ago
  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.
  - cwbriscoe 7mo ago
    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.
    - porridgeraisin 7mo ago
      Yep. Especially for tests with mock data covering all sorts of extreme edge cases.
      - koakuma-chan 7mo ago

jeffrallen 7mo ago

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.

whateveracct 7mo ago
I treat UUIDv4s as 128 random bits and it triggers ppl.
- masklinn 7mo ago
  To be fair that’s literally just a waste of resources. If you want 128 random bits just get 128 random bits from the underlying source, unless your host langage is amazingly deficient it’s just as easy.
- gzread 7mo ago
  It needs several non-random bits to mark it as a v4 or it's not a uuidv4
sevg 7mo ago
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.
- masklinn 7mo ago
  That the problem is already solved does not mean the solution is good. Or that you can’t solve it better. 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.

didip 7mo ago

Based on the conversation, is it actually coming?

0x696C6961 7mo ago
Yes
remus 7mo ago
It's currently listed as a 'Likely accept' https://github.com/orgs/golang/projects/17/views/1 https://github.com/orgs/golang/projects/17/views/1 Generally means it'll be going in unless something new comes up which alters people's thinking.

kittikitti 7mo ago

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.

KingOfCoders 7mo ago

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.

grey-area 7mo ago
I know, I recently upgraded and skipped several releases without any issues with some large codebases. The compatability guarantee is a massive win, so exciting to have a boring language to build on that doesn’t change much but just gradually gets better.
- knorker 7mo ago
  Really? My experience is that of C, C++, Go, Python, and Rust, Go BY FAR breaks code most often. (except the Python 2->3 change) Sure, most of that is not the compiler or standard library, but dependencies. But I'm not talking random opensource library (I can't blame the core for that), but things like protobuf breaking EVERY TIME. Or x/net, x/crypto, or whatever. But also yes, from random dependencies. It seems that language-culturally, Go authors are fine with breaking changes. Whereas I don't see that with people making Rust crates. And multiple times I've dug out C++ projects that I have not touched in 25 years, and they just work.
  - grey-area 7mo ago
    The stdlib has been very very stable since the first release - I still use some code from Go 1.0 days which has not evolved much. The x/ packages are more unstable yes, that's why they're outside stdlib, though I haven't personally noticed any breakage and have never been bitten by this. What breakage did you see? I think protobuf is notorious for breaking (but more from user changes). I don't use it I'm afraid so have no opinion on that, though it has gone through some major revisions so perhaps that's what you mean? I don't tend to use much third party code apart from the standard library and some x libraries (most libraries are internal to the org), I'm sure if you do have a lot of external dependencies you might have a different experience.

matja 7mo ago

> UUID versions 1, 2, 3, 4, 5 are already outdated. Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues. Edit: Context links for reference, these recommend UUIDv4: https://www.cockroachlabs.com/docs/stable/uuid https://www.cockroachlabs.com/docs/stable/uuid https://docs.cloud.google.com/spanner/docs/schema-design#uuid_primary_key https://docs.cloud.google.com/spanner/docs/schema-design#uui...

zadikian 7mo ago
Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering
- jodleif 7mo ago
  Deterministic uuids is a very standard usecase
  - 8organicbits 7mo ago
    You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?
    - eureka7 7mo ago
      I remember using them in a massive SQL query that needed to generate a GIS data set from multiple tables with an ungodly amount of JOINs and sub-queries to achieve ID stability. Don't ask :p For those ~~curious~~ worried, no, this was not a security sensitive context.
    - zadikian 7mo ago
      Common one is if you want two structs deemed "equivalent" based on a few fields to get the same ID, and you're only concerned about accidental collision. There are valid use cases for that, but I've also seen it misused often. v7 rough ordering also helps as a PK in certain sharded DBs, while others want random, or nonsharded ones usually just serial int.

jillesvangurp 7mo ago

Kotlin also added RFC 9562 (which includes the new UUID versions) support to the standard library in version 2.3 recently. It's a multi platform implementation too so it works on native, wasm, jvm and js. I think it makes a lot of sense to default to that now that the IETF RFC has been out for a few years. So, it makes sense for Go to introduce support for this as well.

knodi 7mo ago

Go is often the best part of my work day.

casey2 7mo ago

[flagged]

rkagerer 7mo ago

That's great, but I abhor UUID's. I see them crop up everywhere. IMO, they are decidedly human-unfriendly - particularly to programmers and database admins trying to debug issues. Too many digits to deal with, and they suck up too much column width in query results, spreadsheets, reports, etc. I'm not saying they don't have a place (e.g. when you have a genuine need to generate unique identifiers across completely disconnected locations, and the id's will generally never need to be dealt with by a human). But in practice they've been abused to do everything under the sun (filenames, URL links, user id's, transaction numbers, database primary keys, etc). I almost want to start a website with a gallery of all the examples where they've been unsuitably shoehorned in when just a little more consideration would have produced something more humane. For most common purposes, a conventional, centralized dispenser is better. Akin to the Take-A-Number reels you see at the deli. Deterministic randomization is a thing if you don't want the numbers to count sequentially. Prefixes, or sharding the ID space, is also a thing, if you need uniqueness across different latency boundaries (like disparate datacenters or siloed servers). I've lost count of how many times I've seen a UUID generated when what the designer really should have done is just grab the primary key (or when that's awkward, the result of a GetNextId stored procedure) from their database.

deleted 7mo ago
[deleted]
teeray 7mo ago
I just wish there was some human element to them so they were easier to talk about. Something like: BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO “Which row was it, ‘basketball fish’ or ‘cake potato’? Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looking at all the hex now “it’s the one ending in ‘4ab’”.
- tgv 7mo ago
  There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway. But for exposed values (document ids, customer ids, that kind of thing), it can be awkward if a patient's id is suddenly "CRANKY-...-FART".

MarekKnapek 7mo ago

Is there a way to have benefits of both? Version 7 for better database clustering. And version 4 for complete randomness? So users can not inference nothing from the id? I have an idea: Use version 7 internally, then scramble it before sending to the user. Scrambling could be done by the database or by the server application. It could be as simple as XOR with some 128bit constant, or as resilient as AES encryption. Of course you also need to do unscrambling of IDs coming from users.

grey-area 7mo ago
If privacy is the main concern (as it is in most usage of UUIDs) you could just encrypt the integer primary key instead with something like feistel and avoid the performance problems of UUIDs while still having opaque public identifiers.
8organicbits 7mo ago
Others agree. Check out uuidv47 https://github.com/stateless-me/uuidv47 https://github.com/stateless-me/uuidv47

gethly 7mo ago

Seems pointless. Go should focus on refactoring core libraries, especially net and http, for performance because nbio, gnet and others are kicking its ass. And that is sad, as third party libraries should never perform better than standard library. Also swiss tables were great addition to Go's native maps, but then again there are faster libraries that can give you 3x performance(in case of numeric keys).

kbolino 7mo ago
From nbio's README: For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues. From gnet's README: gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled. [...] gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services. Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface. However, the net/http package is a different story. It indeed isn't very performant, though one should be careful to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers. A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make. [1]: https://pkg.go.dev/github.com/valyala/fasthttp https://pkg.go.dev/github.com/valyala/fasthttp [2]: https://pkg.go.dev/github.com/gofiber/fiber/v3 https://pkg.go.dev/github.com/gofiber/fiber/v3
- gethly 7mo ago
  STD is built on goroutines whereas these performance networking libraries are built on a main reactor loop. Hence the need for refactoring, not just tweaking. Something like http/v2 and net/v2. I know gnet had(has?) issues wit implementing tls because how the entire STD is designed to work. At the time, it was a great piece of software, but by now, it is slow and outdated. A lot of progress has been made since in networking, parsing, serialization, atomics and so on.

sieep 7mo ago

Cool! I love go and things like this will keep bringing me back :)

ollybrinkman 7mo ago

[flagged]

malklera 7mo ago

Wonder about the opinion of the maintainers of the Google package. Will they put it on maintenance mode or continue developing it like usual?

thiht 7mo ago

I don’t really care for Go supporting UUID generation, but UUIDs being a type from the stdlib will be invaluable, if they correctly implement the JSON, Text, database/sql and other standard marshallers/unmarshallers. We seriously need a standard UUID type across the ecosystem, and I’m glad it’s coming. I did an analysis of Go dependencies[1] a few weeks ago and google/uuid is the 2nd most used dependency in the open source ecosystem, so its inclusion will be very impactful. [1]: https://blog.thibaut-rousseau.com/blog/the-most-popular-go-dependency-is/ https://blog.thibaut-rousseau.com/blog/the-most-popular-go-d...

kardianos 7mo ago
I would say the same for dec128. I would love a standard TYPE for dec128, with maybe zero cost std lib to transform it into a mutable uint128 or a zero cost conversion to struct{uint64,int64).

andrewrozumy 7mo ago

[flagged]