8 ms·

UUID package coming to Go standard library

375 points by soypat 7mo ago

andrewrozumy 6mo ago
[flagged]
ollybrinkman 7mo ago
[flagged]
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.
      - 0x696C6961 7mo ago
        Alternative take: don't put draft RFCs into prod
        JimDabell 7mo ago
        It hasn’t been a draft RFC for a couple of years: https://datatracker.ietf.org/doc/rfc9562/ 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.
        0x696C6961 7mo ago
        The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate
        jrpelkonen 7mo ago
        Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.
    - 8organicbits 7mo ago
      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 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.
    - mort96 7mo ago
      There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD https://github.com/google/uuid/compare/v1.6.0...HEAD If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.
- 0x696C6961 7mo ago
  I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.
  - ycombinatrix 7mo ago
    especially when they don't depend on libc.
- PunchyHamster 7mo ago
  The proposal is 3 years old
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
waynesonfire 7mo ago
what a bunch of drama in the comments.
- tptacek 7mo ago
  https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
- 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.
- 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 6mo ago
    I guess open debate and productive discussions?
    - tptacek 6mo 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
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.
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.
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 :)
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).

375 points by soypat 7mo ago

andrewrozumy 6mo ago

[flagged]

ollybrinkman 7mo ago

[flagged]

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.
    - 0x696C6961 7mo ago
      Alternative take: don't put draft RFCs into prod
      - JimDabell 7mo ago
        It hasn’t been a draft RFC for a couple of years: https://datatracker.ietf.org/doc/rfc9562/ 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.
        0x696C6961 7mo ago
        The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate
        jrpelkonen 7mo ago
        Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.
  - 8organicbits 7mo ago
    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 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.
  - mort96 7mo ago
    There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD https://github.com/google/uuid/compare/v1.6.0...HEAD If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.
0x696C6961 7mo ago
I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.
- ycombinatrix 7mo ago
  especially when they don't depend on libc.
PunchyHamster 7mo ago
The proposal is 3 years old

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

waynesonfire 7mo ago

what a bunch of drama in the comments.

tptacek 7mo ago
https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
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.
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 6mo ago
  I guess open debate and productive discussions?
  - tptacek 6mo 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

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.

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.

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

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