Live data from Hacker News

UUID package coming to Go standard library

github.com

81–90 of 260 posts

Re: UUID package coming to Go standard library

#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/spanner/docs/schema-design#uui...

Re: UUID package coming to Go standard library

#82

Earlier quoted context omitted.

Yep. Especially for tests with mock data covering all sorts of extreme edge cases.

Don't use AI for that, it doesn't know what your real data looks like.

Majority of data in typical message-passing plumbing code are a combination of opaque IDs, nominal strings, few enums, and floats. It's mostly OK for these cases, I have found. Esp. in typed languages.

Re: UUID package coming to Go standard library

#83

Earlier quoted context omitted.

> 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? 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 thi…

[flagged]

I gave that example to refute the point that having worked on projects in other languages with tons of third-party dependencies implies that those languages have poor standard libraries. I certainly didn't intend to imply that that means that Go has a poor standard library or that small Go projects often use hundreds of third-party dependencies like JavaScript projects tend to do.

Go's package management is actually one of its strongest points, so I think that it's unsurprising/good that some projects have lots of dependencies. But I still stand by the point that you shouldn't judge a language based on how many dependencies most programs written in it use.

(Except for JavaScript, where I have no problem judging it by the npm craziness :) )

Re: UUID package coming to Go standard library

#84

Earlier quoted context omitted.

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.

What if I generate 16 random bytes and use that as id?

No problem, just don't call it UUID

Re: UUID package coming to Go standard library

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

Re: UUID package coming to Go standard library

#86
post #77
post #66

Earlier quoted context omitted.

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

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?

Re: UUID package coming to Go standard library

#87
post #26

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

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.

A lot of people‘s business model is to to capitalize on LLM anxiety to sell their PUA-tier courses.

Re: UUID package coming to Go standard library

#88

Earlier quoted context omitted.

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.

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.

There has always been a difference on modality and substance.

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.

Personally I try to put as much distance to the modality discussion and get intimate with the substance.

Re: UUID package coming to Go standard library

#89
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…

Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering

Re: UUID package coming to Go standard library

#90

Earlier quoted context omitted.

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.

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:

a = 1

assert a == 1

// many lines here where a is never used

assert a == 1

Yes AI test cases are awesome until you read what it's doing.

Post reply on HN