Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need UUID

henvic.dev

Post reply on HN
Print view View original

61–70 of 199 posts

Re: You Don't Need UUID

#61

Post by lcnPylGDnU4H9OF »

swader999 wrote: post #15

There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.

Someone else implied this in another comment but this line appears at the end of the article:

> If you click and buy any of these from Amazon after visiting the links above, I might get a commission from their Affiliate program.

When one wonders why that was included they might discover that the "short ID" example given near the top of the post is an Amazon link. One might then further wonder what the purpose of this article is.

Re: You Don't Need UUID

#62

Post by Petersipoi »

richbell wrote: post #30
appletrotter wrote: post #23

Earlier quoted context omitted.

Maybe it’s one if the author’s arguments, but that doesn’t mean the author is right.

Sure — it's just a weird question to pose when the author specifically provides their opinion on it. It'd be different to say "I don't think it matters".

You're just nitpicking.

"Does it matter" is a very reasonable response to someone expressing their opinion.

Re: You Don't Need UUID

#63

Post by insanitybit »

I think there's a better "You Don't Need UUID", which is that you probably aren't going to generate so many integers per second that you need to do so in a way that's perfectly collision free.

For example, you can update a postgres integer 1000s of times per second, sequentially, and 100s of 1000s of times per second if you allow for gaps/ unordered sequencing. The reason to choose a UUID is because it doesn't require a db. Totally fair. But you probably already have a db lying around if you're generating UUIDs to begin with?

Or because you need an unguessable token, which a UUID is great for.

But if you have a postgres db around somewhere consider just having a counters table and using that. It'll be fast enough for almost anyone, it'll return smaller tokens, and it'll return tokens that are sequentially allocated (in range. These are nice properties to have!

Re: You Don't Need UUID

#64

Post by thaurelia »

iaaan wrote: post #3

The crux of this argument seems to be that UUIDs are too long? Which I disagree with. I can't memorize them, no, and it would be cumbersome to try to say one aloud, but these aren't situations I've ever found myself in. Does it make the URL in the URL bar longer? Yeah, but does that matter?

> Yeah, but does that matter?

It might, e.g. with embedded systems. I can neither confirm nor deny that we once BOFed our own devices because we assumed that 1200 bytes was a big enough buffer to hold a URL.

Re: You Don't Need UUID

#65

Post by blowski »

bandergirl wrote: post #49
eternityforest wrote: post #21

Earlier quoted context omitted.

It somewhat matters aesthetically, but mostly people are going to ignore long random strings. UUIDs are at least visually kind of white noise, companies have no problem+with+links?that=look&like=this, so why do they care about UUIDs?

apple.com/iphone You can't beat that. Or would you rather receive texts that include the following? https://www.amazon.com/dp/B09V3HZ8B5/?pd_rd_w=DAycy&content-id=amzn1.sym.04e31e32-5e01-4048-8b59-a557891d595f:amzn1.sym.04e31e32-5e01-4048-8b59-a557891d595f&pf_rd_p=04e31e32-5e01-4048-8b59-a557891d595f&pf_rd_r=M1KXM468KNZJV189JBE7&pd_rd_wg=3O1uC&pd_rd_r=e51c1edc-213f-4c6d-b081-e23afa6bf4ab&ref_=vn_s_iwp&qid=1694453553…

Sure, if Amazon sold about 10 products, such a URL scheme would work great. Additionally, this constantly redirects to the latest version of the iPhone, whereas Amazon's URLs are pointing to a specific version.

A more "apples to apples" comparison (pun intended) would be the MagSafe charger:

https://www.apple.com/shop/product/MHXH3AM/A/magsafe-charger...

Re: You Don't Need UUID

#66

Post by afgrant »

dgb23 wrote: post #16

An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance. Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID. In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip. Is it practical to pre-allocate empty entries and reserve a s…

Are there modern databases that can’t readily index on a 128-bit value?

Re: You Don't Need UUID

#67

Post by noisem4ker »

i_am_jl wrote: post #45
iaaan wrote: post #3

The crux of this argument seems to be that UUIDs are too long? Which I disagree with. I can't memorize them, no, and it would be cumbersome to try to say one aloud, but these aren't situations I've ever found myself in. Does it make the URL in the URL bar longer? Yeah, but does that matter?

>Yeah, but does that matter? I'm really reaching here, but an ID that omits special characters is easier to extract from a url, since it can be double-clicked in a URL bar to select it, whereas a GUID with hyphens forces the user to select the beginning and the end of the string. Realistically I think this matters to developers more than users (I hope your application doesn't force users to interact with GUIDs in the…

To select an UUID, double click the first segment and drag the selection till the last segment before releasing. No need to aim for the exact beginning and end characters.

(Maybe that's what you meant, amd yes, it's still clunkier than simply double clicking, but not much)

Re: You Don't Need UUID

#68

Post by SoftTalker »

10000truths wrote: post #38
emodendroket wrote: post #4

> A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from a user’s perspective. I would challenge the premise we appear to be starting from, that the average end user cares to be dealing with any random string of numbers and digits. GUIDs work well, they’re implem…

I think a better argument is that that the identifier needs to be unambiguous in cases where e.g. an ID needs to be communicated over the phone between an end user and a customer service rep. But that is easily solved with encodings like Base58 that exclude ambiguous characters.

Once you get over about 10 characters the chance that the user will skip or repeat a character or misread one goes up.

Sometimes when I order parts for my car the site wants the VIN to verify that the parts are correct for that vehicle. I often have to make two or three attempts at entering it to get it right.

Re: You Don't Need UUID

#69

Post by jholman »

monero-xmr wrote: post #47
swader999 wrote: post #15

There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.

The lack of humbleness and respect for devs who have came before you and solved all these problems is coming through strong. But I myself was that way 15 years ago. It takes a lot of hard lessons to realize everything new is old and we truly stand on the shoulders of 7000 giants all standing on each others’ shoulders.

That's how I feel about UUIDs themselves, and the people who advocate in favour of them. Interesting duality.

Re: You Don't Need UUID

#70

Post by spion »

srameshc wrote: post #24

Read this as I was about to use uuid for id :/

I would use it anyway. This article misses some subtleties that make uuids really great, as well as some real points against uuids (impact of v4 uuids on index access and uuid v7 as a solution to that)
Post reply on HN