Go is often the best part of my work day.
UUID package coming to Go standard library
111–120 of 260 posts
Re: UUID package coming to Go standard library
#112Re: UUID package coming to Go standard library
#113Earlier quoted context omitted.
Basically one guy having a fit when people disagreed with him.
It would appear that person and OP are one in the same.
Damn. I missed that. But yeah OP didn't take it well when people poked hole into his proposed API.
But regardless of API ergonomics, I would love to have UUID v4 and v7 in the stdlib.
Re: UUID package coming to Go standard library
#114> 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…
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
Re: UUID package coming to Go standard library
#115> 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
Deterministic uuids is a very standard usecase
Re: UUID package coming to Go standard library
#116> 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…
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).
https://www.thenile.dev/blog/uuidv7#why-uuidv7 has some details:
"
UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.
".
Also mentioned on HN https://news.ycombinator.com/item?id=45323008
Re: UUID package coming to Go standard library
#117Earlier 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.
Well that depends on your luck, it could be a valid one about 1/16th of the time.
1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble.
The fact that we're discussing this at all is a reasonable argument for using a library function.
Re: UUID package coming to Go standard library
#118Earlier quoted context omitted.
Why it is "huge amount of work" ? Do the code reliably breaks in every new python version ?
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons. For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the…
I think the downvotes are because you did not answer the question you replied to, and instead gave a pretty unrelated rant.
Re: UUID package coming to Go standard library
#119[flagged]
Re: UUID package coming to Go standard library
#120Earlier quoted context omitted.
UUIDs aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life. One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.
The global uniqueness of a uuid v4 is the global uniqueness of pulling 122 bits from a source of entropy. Structure has nothing to do with it, and pulling 128 bits from the same source is strictly (if not massively) superior at that.
I stand corrected. I was thinking of the sequential nature of uuid 7, or SQL servers sequential id.