Wonder about the opinion of the maintainers of the Google package. Will they put it on maintenance mode or continue developing it like usual?
> UUID versions 1, 2, 3, 4, 5 are already outdated.<p>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.<p>Edit: Context links for reference, these recommend UUIDv4:<p><a href="https://www.cockroachlabs.com/docs/stable/uuid" rel="nofollow">https://www.cockroachlabs.com/docs/stable/uuid</a><p><a href="https://docs.cloud.google.com/spanner/docs/schema-design#uuid_primary_key" rel="nofollow">https://docs.cloud.google.com/spanner/docs/schema-design#uui...</a>
Yeah, I thought it was a strange comment, too. v7 is great when you explicitly need monotonicity, but encoded timestamps can expose information about your system. v4 is still very valid.
Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering
If you want 128 bits of randomness why not use 128 bits of randomness? A random UUID presupposes the random number has to fit in UUID format.
Have you considered using two uuids for more randomness
I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.
No, UUIDv8 offers 122 bits for vendor specific or experimental use cases. If you fill those bits randomly, you get the same amount of randomness as a v4. The spec is explicit that it does not replace v4 for random data use case.<p>> To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data.<p><a href="https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2" rel="nofollow">https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2</a>
Really? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).
<a href="https://www.thenile.dev/blog/uuidv7#why-uuidv7" rel="nofollow">https://www.thenile.dev/blog/uuidv7#why-uuidv7</a> has some details:
"
UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.
".<p>Also mentioned on HN <a href="https://news.ycombinator.com/item?id=45323008">https://news.ycombinator.com/item?id=45323008</a>
In more practical terms:-<p>1. Users - your users table may not benefit by being ordered by created_at ( or uuid7 ) index because whether or not you need to query that data is tied to the users activity rather than when they first on-boarded.<p>2 Orders - The majority of your queries on recent orders or historical reporting type query which should benefit for a created_at ( or uuidv7 ) index.<p>Obviously the argument is then you're leaking data in the key, but my personal take is this is over stated. You might not want to tell people how old a User is, but you're pretty much always going to tell them how old an Order is.
It's memory and disk paging both.<p>There's also a hot spot problem with databases. That's the performance problem with autoincrement integers. If you are always writing to the same page on disk, then every write has to lock the same page.<p>Uuidv7 is a trade off between a messy b-tree (page splits) and a write page hot spot (latch contention). It's always on the right side of the b-tree, but it's spread out more to avoid hot spots.<p>That still doesn't mean you should always use v7. It does reversibly encode a timestamp, and it could be used to determine the rate that ids are generated (analogous to the German tank problem). If the uuidv7 is monotonic, then it's worse for this issue.
In distributed databases I've worked with, there's usually something like a B-tree per key range, but there can be thousands of key ranges distributed over all the nodes in the cluster in parallel, each handling modifications in a LSM. The goal there is to distribute the storage and processing over all nodes equally, and that's why predictable/clustered IDs fail to do so well. That's different to the Postgres/MySQL scenario where you have one large B-tree per index.
v7 exposes creation date, and maybe you don't want that. So, depends on use-case
[flagged]
A slow day in Go-news land? :)<p>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. :)
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.
Well fortunately you’re here to take what was a discussion completely unrelated to AI and drag it back around to AI again.<p>If you’re tired of talking about AI, why did you post this?
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.<p>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.
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.
I've seen tests doing:<p>a = 1<p>assert a == 1<p>// many lines here where a is never used<p>assert a == 1<p>Yes AI test cases are awesome until you read what it's doing.
To be fair, many human tests I've read do similar.<p>Especially when folks are trying to push % based test metrics and have types ( and thus they tests assert types where the types can't really be wrong ).<p>I use AI to write tests. Many of them the e2e fell into the pointless niche, but I was able to scope my API tests well enough to get very high hit rate.<p>The value of said API tests aren't unlimited. If I had to hand roll them, I'm not sure I would have written as many, but they test a multitude of 400, 401, 402, 403, and 404s, and the tests themselves have absolutely caught issues such as validator not mounting correctly, or the wrong error status code due to check ordering.
I write assert(a==1) right before the line where a is assumed to be 1 (to skip a division by a) even if I know it's 1. Especially if I know it's 1!
Yep. Especially for tests with mock data covering all sorts of extreme edge cases.
There has always been a difference on modality and substance.<p>This is the same thing as picking a new smart programming language or package, or insisting that Dvorak layout is the only real way forward.<p>Personally I try to put as much distance to the modality discussion and get intimate with the substance.
Right. If AI actually made you more productive, there would be more good software around, and we wouldn't have the METR study showing it makes you 20% slower.<p>AI delivers the feeling of productivity and the ability to make endless PoCs. For some tasks it's actually good, of course, but writing high quality software by itself isn't one.
Ah, yes. LLM-assisted development. That thing that is not at all changing, that thing that different people aren’t doing differently, and that thing that some people aren’t definitely way better at than others.
I swear that some supposedly “smart” people on this website throw their ability to think critically out the window when they want to weigh in on the AI culture war.
B-but the study!<p>I can way with certainty that:
1. LLM-assisted development has gotten significantly, materially better in the past 12 months.<p>2. I would be incredibly skeptical of any study that’s been designed, executed, analysed, written about, published, snd talked about here, within that period of time.<p>This is the equivalent of a news headline stating with “science says…”.
> voice chat ... required skill set<p>But we're still required to go to the office, and talking to a computer on the open space is highly unwelcome
Really? The past two weeks I've been writing code with AI and feel a massive productivity difference, I ended up with 22k loc, which is probably around as many I'd have manually written for the featureset at hand, except it would have taken me months.
A lot of people‘s business model is to to capitalize on LLM anxiety to sell their PUA-tier courses.
Its a small tech bit but a big architecture / management decision.<p>Basically, who runs golang?<p>The perfectionists are correct, UUIDs are awful and if there's a pile of standards that all have small problems the best thing you can do is make a totally new standard to add to the already too long list.<p>The in-the-trenches system software devs want this BAD. Check out <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier#Uses" rel="nofollow">https://en.wikipedia.org/wiki/Universally_unique_identifier#...</a>
They want a library that flawlessly interops with everything on that list, ideally. Something you can trust and will not deprecate a function you need for live code and it just works. I admit a certain affinity to this perspective.<p>The cryptobros want to wait, there is some temporary current turmoil in UUID land. Not like "drama" but things are in flux and it would be horrible for golang to be stuck permanently supporting forever some interim thing that officially gets dropped (or worse, under scrutiny has a security hole or something, but for reverse compatibility with older/present golang would need permanent-ish reverse compatibility) Can't we just wait until 2027 or so? This is not the ideal time to set UUID policy in concrete. Just wait a couple more months or a year or two?
<a href="https://datatracker.ietf.org/doc/html/rfc9562" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc9562</a><p>I think I covered the three groups that are fighting pretty accurately and at least semi fairly, I did make fun of the perfectionists a little but cut me a break everyone makes fun of those guys.<p>So, yeah, a "small technical bit" but its actually a super huge architectural / leadership / management decision.<p>I hope they get it correct, I love golang and have a side thing with tinygo. If you're doing something with microcontrollers that doesn't use networking and you're not locked in to a framework/rtos, just use tinygo its SO cool. Its just fun. I with tinygo had any or decent networking. Why would I need zephyr if I have go routines? Hmm.<p>I've been around the block a few times with UUID-alike situations and the worst thing they could decide is to swing to an extreme. They'll probably be OK this is not golangs first time around the block either.<p>It'll probably be OK. I hope.
Here we see Go haters in their natural habitat, the HN comment section.<p>Watch as they stand at the watering hole, bored and listless. A sad look on their faces, knowing that now that Go has generics, all their joy has left their life. Like the dog that caught his tail, they are confused.<p>One looks at his friends as if to say, "Now what?"<p>Suddenly there is a noise.<p>All heads turn as they see the HN post about UUIDs.<p>One of the members pounces on it. "Why debate this when the entire industry is collapsing?"<p>No reply. Silence.<p>His peers give a half-hearted smile, as if to say, "Thanks for trying" but the truth is apparent. The joy of hating on programming languages is nil when AI is the only thing looking at code any more.<p>The Go hater returns to the waterhole. Defeated.
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.
I know, I recently upgraded and skipped several releases without any issues with some large codebases.<p>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.
Really? My experience is that of C, C++, Go, Python, and Rust, Go <i>BY FAR</i> breaks code most often. (except the Python 2->3 change)<p>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.<p>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 <i>just work</i>.
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.<p>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?<p>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?<p>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.
Odd to me that the focus seems to be on the inactivity of Google's package when <a href="https://github.com/gofrs/uuid" rel="nofollow">https://github.com/gofrs/uuid</a> not only conforms to the newer standard but is actively maintained.
I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.
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: <a href="https://github.com/google/uuid/issues/194" rel="nofollow">https://github.com/google/uuid/issues/194</a>
The proposal is 3 years old
That's great, but I abhor UUID's.<p>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.<p>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.<p>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).<p>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.
At a prior job, there was an internal project code system for tracking billable hours or people assignment kind of thing. Everyone knew the codes of their projects. It was a six digit code, two letters and then four numbers: giving you some ~7 million point space. Company was ~100 years old and only had some 15k codes recorded in all history. The list of codes was manually updated once a quarter by an admin who might add another ten at a time.<p>Some chuckle head decided to replace the system with UUIDs. Now, they are no longer human memorable/readable/writable on paper/anything useful. Even better, they must have used some home grown implementation, because the codes were weirdly sequential. If you ever had to look at a dump of codes, the ids are almost identical minus a digit somewhere in the middle.<p>Destructive change that ruined a perfectly functional system.
> Deterministic randomization is a thing if you don't want the numbers to count sequentially.<p>What are your favorite ways to approach this?<p>I think a maximal period linear feedback shift register might fit well.
I just wish there was some human element to them so they were easier to talk about. Something like:<p>BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH<p>CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO<p>“Which row was it, ‘basketball fish’ or ‘cake potato’?<p>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’”.
There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway.<p>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".
At $dayJob we use (user facing) IDs like this. Select a prefix then add a sufficient number of random alphanumeric characters for your use case.
There's been a lot of historical work done in the past and I used NIST FIPS181 to implement this.<p>Note: FIPS181 was intended for passwords and I was using them as handy short human-readable record IDs as per your post. You probably shouldn't use FIPS181 for passwords in 2026 LOL.<p>Describing FIPS181 as pronounceable is optimistic. However its better than random text wrt human conversations. They start looking like mysterious assembly language mnemonics after awhile.
Based on the conversation, is it actually coming?
Golang lack of support for basic stuff like this is quite annoying.
What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.
Perhaps I’m misunderstanding, but the linked issue seems to address this directly:<p>> Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library.<p>> C#: <a href="https://learn.microsoft.com/en-us/dotnet/api/system.guid.newguid?view=net-7.0&redirectedfrom=MSDN#System_Guid_NewGuid" rel="nofollow">https://learn.microsoft.com/en-us/dotnet/api/system.guid.new...</a><p>> Java: <a href="https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm...</a><p>> JavaScript: <a href="https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand...</a><p>> Python: <a href="https://docs.python.org/3/library/uuid.html" rel="nofollow">https://docs.python.org/3/library/uuid.html</a><p>> Ruby: <a href="https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html#method-c-uuid" rel="nofollow">https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...</a>
You're answering the question of "which languages have UUIDs in their standard libraries" (Javascript is not one of them). That's not the question I'm asking. If you wrote a new Python program today that needed to make HTTP requests, would you rely on the stdlib, or would you pull in a dep? In a Java program, if you were encrypting files or blobs, stdlib or dep?<p>Is C# the language that gives the Go stdlib a run for its money? I haven't used it much. JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.<p>I asked the question I did upthread because, while there are a lot of colorable arguments about what Go did wrong, a complete and practical standard library where the standard library's functionality is the idiomatic answer to the problems it addresses is one of the things Go happens to do distinctively well. Which makes dunking on it for this UUID thing kind of odd.
> If you wrote a new Python program today that needed to make HTTP requests, would you rely on the stdlib, or would you pull in a dep?<p>For a short script, the standard "urllib.request" module [0] works pretty well, and is usually my first choice since it's always installed. For a larger program, I'll usually use a third-party module with more features/async support though, but I'll only do this if I'm using other third-party dependencies anyways.<p>> JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.<p>I checked the top 10 Go repositories on GitHub [1], and all but 1 of them have 30+ direct dependencies listed in their "go.mod" files (and many more indirect ones). Also, both C and JavaScript are well-known for their terrible standard libraries, yet out of all languages, JavaScript programs tend to use the most dependencies, while C programs tend to use the least. So I don't think that the number of dependencies that an average program in a given language uses says anything about the quality of that language's standard library.<p>[0]: <a href="https://docs.python.org/3/library/urllib.request.html" rel="nofollow">https://docs.python.org/3/library/urllib.request.html</a><p>[1]: <a href="https://github.com/trending/go?since=monthly" rel="nofollow">https://github.com/trending/go?since=monthly</a>
<a href="https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand...</a>
Ruby has SecureRandom.uuid and others
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).<p>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.
My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
Obviously PHP
What stuff do you have in mind?<p>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 line-based logging, but getting a traditional format out of it is painful, it lacks features that are common elsewhere, and it's significantly slower than slog's own json support. I can only guess that it was added as an afterthought. (To be fair, I suppose this might make sense if Go is intended only for enterprisey environments.)<p>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?
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>.
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.
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?
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.
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.
Well that depends on your luck, it could be a valid one about 1/16th of the time.
1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble.<p>The fact that we're discussing this at all is a reasonable argument for using a library function.
While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
Nice, thanks and I agree.
I didn't say about 16 random bytes. But you're almost there. You generate 16 random bytes and perform few bitwise operations to set version and variant bits correctly.<p>Not that it matters. I don't even think that there's a single piece of software in the world which would actually care about these bits rather than treating the whole byte array as opaque thing.
Let's call it a valid UUIDv0 - all bits randomized including the version bits :)
What if I generate 16 random bytes and use that as id?
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.
I had a similar thought a while back. Looking at the code for existing UUID projects, issues they fixed, and in some cases the CVEs, is a good way to form a different opinion.
You can say this for everything that has built-in support.
It makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons
What other basic stuff are you thinking of?
Go has one of the best stdlibs of any language. I'd go as far and say it's the #1 language where the stdlib is the most used for day to day programming. cut the bullshit
Now do Javascript.
<a href="https://github.com/rs/xid" rel="nofollow">https://github.com/rs/xid</a>
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.<p>So, it makes sense for Go to introduce support for this as well.
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.
Others agree. Check out uuidv47<p><a href="https://github.com/stateless-me/uuidv47" rel="nofollow">https://github.com/stateless-me/uuidv47</a>
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.
Cool! I love go and things like this will keep bringing me back :)
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.
Go is often the best part of my work day.
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.<p>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).
From nbio's README:<p><pre><code> 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.
</code></pre>
From gnet's README:<p><pre><code> 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.
</code></pre>
Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface.<p>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.<p>A big part of why net/http is relatively slow is <i>also</i> 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.<p>[1]: <a href="https://pkg.go.dev/github.com/valyala/fasthttp" rel="nofollow">https://pkg.go.dev/github.com/valyala/fasthttp</a><p>[2]: <a href="https://pkg.go.dev/github.com/gofiber/fiber/v3" rel="nofollow">https://pkg.go.dev/github.com/gofiber/fiber/v3</a>
what a bunch of drama in the comments.
It’s kind of ridiculous to argue against UUID being part of the standard package for a language largely aimed at servers. At that point why even have any crypto functions or any of the bigger stuff it already has if the argument is 3rd party libs are enough?
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).
People are weird. A few days ago someone on /r/Java was arguing that a basic JSON parser shouldn’t be in the standard library.
I would really urge everyone to actually engage in the arguments people are making.<p>Go’s core design philosophy is stability. This means backwards compatibility forever. But really, even more than that. The community is largely against “v2” libraries. After the first version is introduced, Go devs trend towards stability, live with its flaws, and are super hesitant to fix things with a “v2”.<p>There have been exceptions. After 20 years of the frankly horrible json library, a v2 one is in the works.<p>Most of the uuid concerns come from a place of concern. After the api is added to the standard library, it will be the canonical api <i>forever</i>.<p>There are surely pros and cons to this design philosophy. I just don’t understand why people who disagree with Go’s core goals don’t just use a different language? Sorry to take a jab here, but are we really short on programming languages that introduce the wrong v1 api, so then the language ends up with codebases that depend on v1, v2, and v3? (Looking at you Java, Python, and C#)
Adding UUID to the standard library is defensible for a server-focused language, but making it part of the stdlib binds maintainers to long-term compatibility and support, so the debate should focus on API surface and long term maintenance rather than whether third-party packages exist.<p>If added, keep the scope small: implement RFC 4122 v4 generation using crypto/rand.Read with correct version and variant bit handling, provide Parse and String, MarshalText and UnmarshalText, JSON Marshal and Unmarshal hooks, and database/sql Scanner and Valuer, and skip v1 MAC and time based generation by default because of privacy and cross-platform headaches.
<a href="https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email" rel="nofollow">https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email</a>
Basically one guy having a fit when people disagreed with him.
Welcome to literally any Go thread.
Am I the only one who hates UUIDs and doesn't see the point of them?<p>Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else.<p>Argh.
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.<p>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.
That the problem is already solved does not mean the solution is good. Or that you can’t solve it better.<p>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.<p>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.
Why the hate though? Is someone forcing you to use them against your will? If you need 128 bits of crypto.Rand() for your usecase, you can just use that right?
I treat UUIDv4s as 128 random bits and it triggers ppl.
It needs several non-random bits to mark it as a v4 or it's not a uuidv4
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.
they should be prefixed with something human readable so you can tell a service bot api key from a human developer api key or whatever.
I hate UUIDv4, don't care about the rest. UUIDv4 is just random bytes with hyphens inserted in random places and some bytes reserved to indicate that this is in fact a UUID. This is wasteful and stupid
UUIDs aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life.<p>One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.
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.<p>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.<p>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...
It's an open Github issues thread. What do you expect?
Which is why I changed from being on Gonuts during pre-1.0 days to only touch Go if I really have to.<p>However I would still advocate for it over C in scenarios easily covered by TinyGo and TamaGo.
I mean that's pretty common in most OSS projects just because you have free entry to the debate.<p>If you want to see go-uniquie highschool debate club, look at Go team attitude to fixing logging, where community proposed multiple ways of solving it, Go team rejected all of them and then made massive navel-gazing post that could be summed up "well, there is multiple proposals THAT MEANS PEOPLE ARE UNSURE ON THE ISSUE so we won't do shit"<p>...then removed every question related to go logging (that were common in previous ones) in their yearly survey
It's called bikeshedding. It's highly annoying, but unfortunately every public mailing list or tracker is prone to it.<p>The maintainers did the right thing by just saying "no."
UUIDs are one of those useless things standards people create so they can plop it in other standards. They don't, have never and can never solve a real problem, only hypothetical meta problems. That Go team probably sees UUID v7 and LOL'd their underpants off, you couldn't get it right the first 6 times? GTFO
The UUID stdlib debate reveals a deeper tension in API design: when does standardization help vs hurt?<p>UUIDs won because they're "good enough" - collision-resistant without coordination. But v7's timestamp ordering breaks that independence by leaking information. Now you need to reason about clock sync, monotonicity, privacy.<p>For distributed systems, I increasingly see folks moving to: use v7 internally (btree efficiency matters), expose v4 externally (don't leak creation order to clients). Add a mapping layer at the API boundary.<p>The real lesson: IDs are part of your API contract. If clients can infer system behavior from ID structure (request rate, shard assignment, rollout timing), that's signal you may not want to transmit. Standards help, but context still matters.