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

141–150 of 260 posts

Re: UUID package coming to Go standard library

#141

Post by YesThatTom2 »

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

Here we see Go haters in their natural habitat, the HN comment section.

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.

One looks at his friends as if to say, "Now what?"

Suddenly there is a noise.

All heads turn as they see the HN post about UUIDs.

One of the members pounces on it. "Why debate this when the entire industry is collapsing?"

No reply. Silence.

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.

The Go hater returns to the waterhole. Defeated.

Re: UUID package coming to Go standard library

#142

Post by 8organicbits »

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.

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.

Re: UUID package coming to Go standard library

#143

Post by 1f60c »

out_of_protocol wrote: post #114
bootsmann wrote: post #105

Earlier quoted context omitted.

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

v7 exposes creation date, and maybe you don't want that. So, depends on use-case

I think I read something once about using v7 internally and exposing v4 in your API.

Re: UUID package coming to Go standard library

#144

Post by sethammons »

gzread wrote: post #138
sethammons wrote: post #106

Earlier quoted context omitted.

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.

You mean he could read it or he could write a parser or he could use a dependency?

Use a dependency. It was a wild pattern that still confuses me years later.

Literal interview: concurrently hit these endpoints that returns json and sum the total of values returned. Handle any 400 or 500 level http errors.

Literal former Googlers and flubbing the interview. They would spend too much time setting up an IDE and project, not be sure how to handle errors, and unable to parse the json. We eventually added a skeleton java project and removed json from the api, allowing text only responses. I learned java people don't set up projects or deal with json. It is the only explanation

Re: UUID package coming to Go standard library

#145

Post by nightfly »

YesThatTom2 wrote: post #141
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. :)

Here we see Go haters in their natural habitat, the HN comment section. 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. One looks at his friends as if to say, "Now what?" Suddenly there is a noise. All heads turn as they see the HN post about UUIDs. O…

I think you're massively misreading the tone of the comment you're relying to

Re: UUID package coming to Go standard library

#146

Post by gethly »

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

Re: UUID package coming to Go standard library

#147

Post by can3p »

PunchyHamster wrote: post #76
remus wrote: post #58

Earlier quoted context omitted.

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.

Why it is "huge amount of work" ? Do the code reliably breaks in every new python version ?

Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers

Re: UUID package coming to Go standard library

#148

Post by da_chicken »

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…

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.

Re: UUID package coming to Go standard library

#149

Post by da_chicken »

gzread wrote: post #128
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…

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.

122 bits of randomness.

It's the same reason we use UTF-8. It's well supported. UUIDs are well supported by most languages and storage systems. You don't have to worry about endianness or serialization. It's not a thing you have to think about. It's already been solved and optimized.

Re: UUID package coming to Go standard library

#150

Post by 8organicbits »

pclmulqdq wrote: post #129
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…

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.

> To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data.

https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2

Post reply on HN