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

201–210 of 260 posts

Re: UUID package coming to Go standard library

#201

Post by vips7L »

sethammons wrote: post #144
gzread wrote: post #138

Earlier quoted context omitted.

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 add…

In my experience it’s Googler’s not Java people. All of my friends at Google tell me how everything is already set up for them.

Re: UUID package coming to Go standard library

#202

Post by zadikian »

efilife wrote: post #169
da_chicken wrote: post #166

Earlier quoted context omitted.

Sure. Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time. Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deseri…

You are really making it seem like a huge problem. Generate random bytes, serialize to a string and store in a db. Done A downvote tells me nothing. Please tell me what I'm missing, maybe I could learn something

It's not a huge problem. Uuid adds convenience over reinventing that wheel everywhere. And some of those wheels would use the wrong random or hash or encoding.

(Downvote wasn't me)

Re: UUID package coming to Go standard library

#203

Post by jrpelkonen »

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

Earlier quoted context omitted.

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

Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.

Re: UUID package coming to Go standard library

#205

Post by da_chicken »

10000truths wrote: post #175
da_chicken wrote: post #166

Earlier quoted context omitted.

Sure. Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time. Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deseri…

None of these are rocket-science problems, they're just standardization issues. You build a library with your generate_id/serialize_id/deserialize_id functions that work with a wrapper type, and tell your devs to use that library. UUID libraries are exactly that, except backed by an RFC.

Of course they're not rocket science. But, the question here is, "Why don't you use random 16 bytes instead of a UUIDv4?" It's not a question about rocket science. The answer is still, "Because UUIDv4 is still a better way to do it." The UUID standard solves the second and third tier problems and knock-on effects you don't think about until you've run a system for awhile, or until you start adding multiple information systems that need to interact with the same data.

But, using UUIDv4 shouldn't be rocket science, either. UUID support should be built in to a language intended for web applications, database applications, or business applications. That's why you're using Go or C# instead of C. And Go is somewhat focused on micro-service architectures. It's going to need to serialize and deserialize objects regularly.

Re: UUID package coming to Go standard library

#206

Post by alecbz »

LtWorf wrote: post #90
cwbriscoe wrote: post #55

Earlier quoted context omitted.

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.

It's good at writing/updating tedious test cases and fixtures when you're directing it more closely. But yes, it's not as great at coming up with what to test in the first place.

Re: UUID package coming to Go standard library

#207

Post by akerl_ »

LtWorf wrote: post #153
Hendrikto wrote: post #118

Earlier quoted context omitted.

I think the downvotes are because you did not answer the question you replied to, and instead gave a pretty unrelated rant.

I'm explaining that yes, code does break every new python version? Mostly because they touch the stdlib instead of just leaving it be.

The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.

And then you answered about downstream code breakage totally outside the std lib.

Re: UUID package coming to Go standard library

#208

Post by bastawhiz »

gzread wrote: post #168
da_chicken wrote: post #166

Earlier quoted context omitted.

Sure. Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time. Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deseri…

How's your UUIDv4 generated? > Are you sure the way you're serializing it is how the remote system will deserialize it? It's 16 bytes. There's no serialization.

> There's no serialization.

Hex encoding with hyphens in the right spot isn't serialization?

Re: UUID package coming to Go standard library

#209

Post by bastawhiz »

pphysch wrote: post #195
wredcoll wrote: post #170

Earlier quoted context omitted.

What do they look like when I put it in a url?

Use whatever encoding you want? Base64 is probably one of the most practical, but you're not obligated to use that.

UUIDs don't use base64

Re: UUID package coming to Go standard library

#210

Post by [deleted] »

bastawhiz wrote: post #208
gzread wrote: post #168

Earlier quoted context omitted.

How's your UUIDv4 generated? > Are you sure the way you're serializing it is how the remote system will deserialize it? It's 16 bytes. There's no serialization.

> There's no serialization. Hex encoding with hyphens in the right spot isn't serialization?

[deleted]
Post reply on HN