uuid VS ulid

Digging deeper now I found these links, so basically it uses `ThreadRng` from the `rand` crate. It mentions that the `ThreadRng` also seeds data from `OsRng` so I guess it's not much different, but I'm no expert in this area so I will post the links so if you find anything useful, please share:https://github.com/uuid-rs/uuid/issues/529https://github.com/uuid-rs/uuid/pull/545https://docs.rs/rand/latest/rand/rngs/struct.ThreadRng.html

Upgrade uuid to 1.0

Those aren’t bytes — they’re integers of various sizes. (Hint: do not use integer types in C code for portable data structures. ntohl, etc are a mess. Just use arrays of bytes.)

I don’t know the whole history, but MS somehow took this structure at face value and caused problems like this:

https://github.com/uuid-rs/uuid/issues/277

So, if you want to do anything (e.g. sorting) that depends on the representation of a UUID (or even depends on converting between string and binary representations), be aware that UUIDs coming from Windows may be little-endian. In my book, this is a Windows bug, but opinions may differ here.

A: For uuid, the maintainer perfers to wait for stdsimd instead of maintaining different implementations. https://github.com/uuid-rs/uuid/issues/561.

I really like ULID for this problem (e.g: https://github.com/ahawker/ulid)

- same number of bytes as UUID

- start with a date, so has great locality. Plus you get extra information in the uid that you can extract.

- can be created from an existing date or uuid, and exported to a uuid, so there is a migration path

As the author of a popular ULID implementation in python[1], the spec has no stewardship anymore. The specification repo[2] has plenty of open issues and no real guidance or communication beyond language implementation authors discussing corner cases. The monotonic functionality is ambiguous (at best) and is implemented differently per-languages [3].

Functionality, UUIDv7 might be the _same_ but the hope would be for a more rigid specification for interoperability.

[1]: https://github.com/ahawker/ulid

[2]: https://github.com/ulid/spec

[3]: https://github.com/ulid/spec/issues/11

Looks similar to ULID[0] (I am the author of a popular python implementation[1]).

It appears to have a similar constraint that two ID's generated within the same timestamp (ms, ns) have no strong guarantee of ordering. That might not be a deal breaker depending on your use case but something to consider.

* https://github.com/ulid/spec

* https://github.com/ahawker/ulid