5 ms·
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 featu
by TeeWEE 10y ago
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.
- _ak 10y agoYou just compared UUIDs with ULIDs.
- cloudhead 10y agoMaybe he means programatically?
- icholy 10y agoI think he's joking.
- throwaway98237 10y agoAnd nailed it.
- sp332 10y agoThat's contrasting, not comparing.
- _ak 10y agohttps://www.google.com/search?q=to+compare+definition https://www.google.com/search?q=to+compare+definition
- tsenart 10y agoULIDs are meant to be compared with Time UUIDs in particular. See: https://www.famkruithof.net/guid-uuid-timebased.html https://www.famkruithof.net/guid-uuid-timebased.html
- tyingq 10y ago>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.
- jdmichal 10y agoI've never seen a UUID in base-64 instead of hex...
- tyingq 10y agoHex is also case insensitive. Was trying to answer why case insensitive might be an advantage.
- jdmichal 10y agoSure. 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.
- tyingq 10y agoMy guess is that the README was mostly copied from here: https://github.com/alizain/ulid 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.
- vertex-four 10y ago> 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.
- clinta 10y agoIf 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.
- foobarian 10y ago> 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.