Hacker News Reader

Comment by TeeWEE | Hacker News Reader

Note. You cant compare ULID with UUID's

  - An ulid is "sortable". But the whole point of an UUID is a random unique ID. Non guessable. Sortable is not a feature 
    you normally want from an uuid. And still UUIDs are still sortable. But it doesnt have any meaning. 
  - An ulid also encodes Time, an uuid doesn't. 
  - An uuid has less change of clashing: Its 128 bit vs 80 bit for ulid.
  - An uuid is also url safe.
  - An ulid is case insensitive. I don't see how this is an advantage.

View on HN

You just compared UUIDs with ULIDs.

Maybe he means programatically?

I think he's joking.

And nailed it.

That's contrasting, not comparing.

https://www.google.com/search?q=to+compare+definition

If you sort a list of ULIDs they sorted by time of creation, with random order only among ULIDs created in the same millisecond. As far as guessable, you still have 80 random bits. Though I'll admit I'm not qualified to comment on whether the difference between 80 and 128 bits is significant when you're trying to make sure your identifiers are not guessable.

As for less chance of clashing, 128 vs 80 bits. 80 bits is only within the same millisecond. The 128 bits is for the lifetime of your application. Based on my basic understanding of the birthday paradox, there is a 50% chance of collision if you have 2^40 ULIDs generated during the same millisecond. And there is a 50% chance of collision if you have 2^64 UUIDs generated during the lifetime of the application.

Case insensitivity and the chosen character set is an advantage if you want to use this ID as a filename without having to worry about the limits of the filesystem.

>An ulid is case insensitive. I don't see how this is an advantage.

It's helpful if you've ever had to read something like a ULID over the phone. Base64 isn't fun in that situation.

I've never seen a UUID in base-64 instead of hex...

Hex is also case insensitive. Was trying to answer why case insensitive might be an advantage.

Sure. I just don't even understand why it's a point in a discussion about UUID (hex) vs ULID (base-32), since both are case-insensitive... Which I think is why TeeWEE was stating that it's not really an advantage for ULID.

My guess is that the README was mostly copied from here: https://github.com/alizain/ulid

Which has a similar list, but presents them as features/facts, not advantages.

Edit: Perhaps it was noted to specifically call out that it maintains case insensitivity, even though it's choosing a more dense approach than just hex.

> An uuid has less change of clashing: Its 128 bit vs 80 bit for ulid.

Actually... that's 80 bits for the "random" part of the ULID, which only disambiguates within the same millisecond.

ULIDs are meant to be compared with Time UUIDs in particular. See: https://www.famkruithof.net/guid-uuid-timebased.html

> But the whole point of an UUID is a random unique ID. Non guessable. Sortable is not a feature you normally want from an uuid.

Why so? As the name says they just need to be universally unique. Even relying purely on randomness seems bad, because you are at the mercy of the entropy source. Mess that up and you can end up with nasty problems throughout your system.

Reply on news.ycombinator.com