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

51–60 of 260 posts

Re: UUID package coming to Go standard library

#51

Post by 0x696C6961 »

serial_dev wrote: post #49
vzaliva wrote: 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.

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.

Re: UUID package coming to Go standard library

#52

Post by masklinn »

sevg wrote: post #41
jeffrallen wrote: post #35

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.

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…

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.

Re: UUID package coming to Go standard library

#53

Post by 0x696C6961 »

JimDabell wrote: post #34
0x696C6961 wrote: post #27

Earlier quoted context omitted.

Alternative take: don't put draft RFCs into prod

It hasn’t been a draft RFC for a couple of years: 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.

The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate

Re: UUID package coming to Go standard library

#55

Post by cwbriscoe »

0x696C6961 wrote: post #51
serial_dev wrote: post #49

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.

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.

Re: UUID package coming to Go standard library

#57

Post by [deleted] »

masklinn wrote: post #52
sevg wrote: post #41

Earlier quoted context omitted.

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…

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.

[deleted]

Re: UUID package coming to Go standard library

#58

Post by remus »

0x696C6961 wrote: post #38
jen20 wrote: post #29

Earlier quoted context omitted.

Like Python though, while the batteries are included, many of them are dead.

It begs the question, why don't these languages put out a v2 stdlib?

Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.

Re: UUID package coming to Go standard library

#60

Post by porridgeraisin »

cwbriscoe wrote: post #55
0x696C6961 wrote: post #51

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.

Yep. Especially for tests with mock data covering all sorts of extreme edge cases.
Post reply on HN