search

nicoburns / blessed-rs

A community guide to the Rust ecosystem
https://blessed.rs
1.32k stars 77 forks source link

Add ULIDs to UU/LIDs #27

Closed simonsan closed 2 years ago

djc commented 2 years ago

It's not obvious to me that ulid should go first, although I think it might make sense to mention it given that it's supposedly a better alternative to UUIDs? Probably still lots of cases where UUIDs are just mandated. This is also an 80k vs 8M recent downloads difference, which is pretty sizable.

nicoburns commented 2 years ago

Agreed that the uuid crate should remain the first recommendation. Especially as the new v6/v7/v8 UUIDs cover pretty much the same use case as ULIDs. https://github.com/uuid-rs/uuid/issues/523

simonsan commented 2 years ago

It's not obvious to me that ulid should go first, although I think it might make sense to mention it given that it's supposedly a better alternative to UUIDs? Probably still lots of cases where UUIDs are just mandated. This is also an 80k vs 8M recent downloads difference, which is pretty sizable.

I just sorted it alphabetically, not by recommendation. It's different use cases, basically, so I wouldn't compare them via a “use this over this”. Do UUIDv6-8 already have an implementation in the rust ecosystem?

That being said, what is the metric for ordering within a category, I think by name makes the most sense, as otherwise it's more subjective (which one is better for a certain use case) and subject to change (if it would be ordered by downloads, which would need automatic updating and would have a bad UX because things would change within a category).

My assumption is that this list is only giving an overview over certain things and developers still need to do research on their own which crate fits their needs best, for example.

In addition: I'm not sure if I would enforce sorting for any metric already in the json I probably would rather recommend adding an order field, so it can be rendered on the client side in a certain order. Or add another field that makes the metric transparent for what it can be ordered on the frontend.

djc commented 2 years ago

That being said, what is the metric for ordering within a category, I think by name makes the most sense, as otherwise it's more subjective (which one is better for a certain use case) and subject to change (if it would be ordered by downloads, which would need automatic updating and would have a bad UX because things would change within a category).

On HN, @nicoburns mentioned:

The options are ordered, so you can effectively get this by just reading the top 2 and ignoring the others. Perhaps this could be made clearer though. I've been trying to balance keeping the list short with providing some context about why you perhaps shouldn't other options.

I think the entire point is that the site's recommendations are, too some extent, subjective. It's a curated collection.

In addition: I'm not sure if I would enforce sorting for any metric already in the json I probably would rather recommend adding an order field, so it can be rendered on the client side in a certain order. Or add another field that makes the metric transparent for what it can be ordered on the frontend.

This doesn't make sense. JSON arrays have a well-defined order, there's no reason to add a separate value to order values against.

simonsan commented 2 years ago

On HN, @nicoburns mentioned:

The options are ordered, so you can effectively get this by just reading the top 2 and ignoring the others. Perhaps this could be made clearer though. I've been trying to balance keeping the list short with providing some context about why you perhaps shouldn't other options.

I think the entire point is that the site's recommendations are, too some extent, subjective. It's a curated collection.

Ah, I didn't read that. Hmm, then contributions don't make any sense if it's solely a personal project.

In addition: I'm not sure if I would enforce sorting for any metric already in the json I probably would rather recommend adding an order field, so it can be rendered on the client side in a certain order. Or add another field that makes the metric transparent for what it can be ordered on the frontend.

This doesn't make sense. JSON arrays have a well-defined order, there's no reason to add a separate value to order values against.

It's only the format it is persisted in, it doesn't really say anything about the data contained in it and if the order of items in an array is really the "right order" for every use case. But I "ordered" it alphabetically to circumvent understand any (internal) metric behind this project.

Anyway, going to close this PR as it doesn't really make sense it seems to add ULID then.