Hacker News new | ask | show | jobs
by kcartlidge 1261 days ago
> GUIDs do not have a consistent sort order

I didn't write that they "have a consistent sort order" (they don't), I wrote that they will "consistently sort in the same order".

In other words I was not saying they are generated in a particular order, but that once you have them they will sort consistently - that is, requesting the data multiple times will always return them in the same order. In context it wasn't a comment about their inherent nature in any way, more about what the stable sorting might make people believe about that nature.

My point is that whilst both GUIDs and ULIDs have stable ordering (as per the above), the sort order of GUIDs very clearly has no meaning whereas the sort order of ULIDs gives the impression that it might without further consideration. This is simple fact; the issue is the weight you put on that fact. To me it is dangerous, but feel free to differ.

1 comments

I think you missed facts that I already referenced in my post: v1 GUIDs have timestamps and machine keys for sorting. The proposed v6 and v7 UUIDs have timestamps again. The "no meaning of GUID sort" today again seems purely an accident of v4 becoming the most common type of GUID/UUID not an actual intent by GUID/UUID developers especially given how important sorting was to v1 GUIDs.

(That's part what makes GUID/UUID sort so inconsistent today: there's still a major database used by lots of applications that sorts even v4 UUIDs by v1 machine key then v1 timestamp!) The sort of GUIDs have too many meanings in practice today, even when you assume the majority of GUIDs you see are v4 UUIDs.