Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUID package coming to Go standard library

github.com

Post reply on HN
Print view View original

101–110 of 260 posts

Re: UUID package coming to Go standard library

#101

Post by mort96 »

rafram wrote: post #17
da_chicken wrote: post #12

Earlier quoted context omitted.

While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194

The RFC isn’t changing, is it?

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

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.

Re: UUID package coming to Go standard library

#102

Post by fshr »

tptacek wrote: post #33
JimDabell wrote: post #23

Earlier quoted context omitted.

Perhaps I’m misunderstanding, but the linked issue seems to address this directly: > Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library. > C#: https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/A…

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? Is C# the language that gives the Go stdlib a run for i…

https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand...

Re: UUID package coming to Go standard library

#103

Post by sethammons »

LtWorf wrote: post #91
orangeisthe wrote: post #64

Earlier quoted context omitted.

[flagged]

Open the python documentation if you're curious of why people are downvoting you.

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.

Re: UUID package coming to Go standard library

#104

Post by matja »

efilife wrote: post #86
matja wrote: post #77

Earlier quoted context omitted.

You aren't supposed to store the hyphens, and that's the same for all versions.

What if I want an ID in the URL? Parse it back and forth? And what if for example, nodejs's UUID api only gives me the string representation of the ID?

To minimize the storage space while having a URL-safe representation, yeah you'd want to serialise/deserialise on the boundary of presenting it to API consumers. I think the same for any ID that has an efficient binary representation as well as needing to represent it in ASCII.

Re: UUID package coming to Go standard library

#105

Post by bootsmann »

matja wrote: post #81

> 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://docs.cloud.google.com…

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

Re: UUID package coming to Go standard library

#106

Post by sethammons »

vips7L wrote: post #22
azinman2 wrote: post #11

Earlier quoted context omitted.

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?

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.

Anecdote: about 8 years ago, I was interviewing hundreds of candidates for a non-java shop but you could interview in java if desired. One java dev ever was able to figure out parsing json with ease. Every single other java interview the person struggled with json. It was weird.

Re: UUID package coming to Go standard library

#107

Post by sethammons »

PunchyHamster wrote: post #80
fragmede wrote: post #47

Earlier quoted context omitted.

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.

hahahaha as if humans wouldn't just give their hey to the bot

That misses the point. The point is for easy validation that the key was generated appropriately. Many api keys have a standard prefix for just this reason. It especially helps on documentation where the key name might be confused with the value: "your key starts with hnkey-"

Re: UUID package coming to Go standard library

#108

Post by matja »

bootsmann wrote: post #105
matja wrote: post #81

> 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://docs.cloud.google.com…

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

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.

Re: UUID package coming to Go standard library

#109

Post by Razengan »

vbezhenar wrote: post #56
therealdrag0 wrote: post #3

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

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.

You can say this for everything that has built-in support.

Re: UUID package coming to Go standard library

#110

Post by arccy »

matja wrote: post #81

> 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://docs.cloud.google.com…

[flagged]
Post reply on HN