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

221–230 of 260 posts

Re: UUID package coming to Go standard library

#221

Post by Dylan16807 »

efilife wrote: post #66
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.

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

Is reserving 6 bits really that bad?

You can use different encodings based on context, just like with a random blob of bytes.

Re: UUID package coming to Go standard library

#222

Post by jandrewrogers »

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 think "outdated" was a poor choice of words. It is a failure to meet application requirements, which has more to do with design than age. Every standardized UUID is expressly prohibited in some application contexts due to material deficiencies, including v4. That includes newer standards like v7 and v8.

In practice, most orgs with sufficiently large and complex data models use the term "UUID" to mean a pure 128-bit value that makes no reference to the UUID standard. It is not difficult to find yourself with a set of application requirements that cannot be satisfied with a standardized UUID.

The sophistication of our use case scenarios for UUIDs exceeds their original design assumptions. They don't readily support every operation you might want to do on a UUID.

Re: UUID package coming to Go standard library

#223

Post by gethly »

kbolino wrote: post #188
gethly wrote: post #146

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

From nbio's README: For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues. From gnet's README: gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the p…

STD is built on goroutines whereas these performance networking libraries are built on a main reactor loop. Hence the need for refactoring, not just tweaking.

Something like http/v2 and net/v2. I know gnet had(has?) issues wit implementing tls because how the entire STD is designed to work. At the time, it was a great piece of software, but by now, it is slow and outdated. A lot of progress has been made since in networking, parsing, serialization, atomics and so on.

Re: UUID package coming to Go standard library

#224

Post by grey-area »

knorker wrote: post #214
grey-area wrote: post #196

Earlier quoted context omitted.

The stdlib has been very very stable since the first release - I still use some code from Go 1.0 days which has not evolved much. The x/ packages are more unstable yes, that's why they're outside stdlib, though I haven't personally noticed any breakage and have never been bitten by this. What breakage did you see? I think protobuf is notorious for breaking (but more from user changes). I don't use it I'm afraid so ha…

Well, for C++ the backwards compatability is even better. Unless you're using `gets()` or `auto_ptr`, old C++ code either just continue to compile perfectly, or was always broken. Sure, the Go standard library is in some sense bigger, so it's nice of them to not break that. But short of a Python2->3 or Perl5->6 migration, isn't that just table stakes for a language? The only good thing about Go is that its standard l…

But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly.

This is not my experience with my own or third party code. I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade, and perhaps one caused by changes to a third party library (sendgrid, who changed their API with breaking changes, not really a Go problem).

A 'bit-rotting timer' isn't very specific or convincing, do you have examples in mind?

Re: UUID package coming to Go standard library

#225

Post by hamburglar »

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 really not that complicated a problem. Don’t worry, you’ll certainly be able to solve all the problems yourself as you encounter them. What you end up with will be functionally equivalent to a proper UUID and will only have cost you man-months of pain, but then you will be able to truly understand the benefit of not spending your effort on easy problems that someone solved before you.

Re: UUID package coming to Go standard library

#226

Post by buffalobuffalo »

8organicbits wrote: post #159
jodleif wrote: post #115

Earlier quoted context omitted.

Deterministic uuids is a very standard usecase

You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?

I use these a lot. My favorite use case is templates, especially ones that were not initially planned in the architecture.

Let's say i have some entity like an "organization" that has data that spans several different tables. I want to use that organization as a "parent" in such a way where i can clone them to create new "child" organizations structured the same way they are. I also want to periodically be able to pull changes from the parent organization down into the child organization.

If the primary keys for all tables involved are UUIDs, I can accomplish this very easily by mapping all IDs in the relevant tables `id => uuid5(id, childOrgId)`. This can be done to all join tables, foreign keys, etc. The end result is a perfect "child" clone of the organization with all data relations still in place. This data can be refreshed from the parent organization any time simply by repeating the process.

Re: UUID package coming to Go standard library

#227

Post by thiht »

I don’t really care for Go supporting UUID generation, but UUIDs being a type from the stdlib will be invaluable, if they correctly implement the JSON, Text, database/sql and other standard marshallers/unmarshallers. We seriously need a standard UUID type across the ecosystem, and I’m glad it’s coming.

I did an analysis of Go dependencies[1] a few weeks ago and google/uuid is the 2nd most used dependency in the open source ecosystem, so its inclusion will be very impactful.

[1]: https://blog.thibaut-rousseau.com/blog/the-most-popular-go-d...

Re: UUID package coming to Go standard library

#228

Post by kardianos »

thiht wrote: post #227

I don’t really care for Go supporting UUID generation, but UUIDs being a type from the stdlib will be invaluable, if they correctly implement the JSON, Text, database/sql and other standard marshallers/unmarshallers. We seriously need a standard UUID type across the ecosystem, and I’m glad it’s coming. I did an analysis of Go dependencies[1] a few weeks ago and google/uuid is the 2nd most used dependency in the open…

I would say the same for dec128. I would love a standard TYPE for dec128, with maybe zero cost std lib to transform it into a mutable uint128 or a zero cost conversion to struct{uint64,int64).

Re: UUID package coming to Go standard library

#229

Post by kbolino »

3eb7988a1663 wrote: post #183
isbvhodnvemrwvn wrote: post #155

Earlier quoted context omitted.

Python had enough fun with 2 to 3 transition I think.

Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption. I will be forever mad that they did not use t…

> They also failed to initially offer any automatic porting tooling which could have increased adoption.

Maybe it wasn't very good, but 2to3 was there from the start:

https://docs.python.org/3.0/library/2to3.html

Re: UUID package coming to Go standard library

#230

Post by [deleted] »

gethly wrote: post #223
kbolino wrote: post #188

Earlier quoted context omitted.

From nbio's README: For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues. From gnet's README: gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the p…

STD is built on goroutines whereas these performance networking libraries are built on a main reactor loop. Hence the need for refactoring, not just tweaking. Something like http/v2 and net/v2. I know gnet had(has?) issues wit implementing tls because how the entire STD is designed to work. At the time, it was a great piece of software, but by now, it is slow and outdated. A lot of progress has been made since in net…

[deleted]
Post reply on HN