spec VS ulid

There was recently score.dev, but that is also just used by one tool.

Yesterday I was thinking about the roadmap and the discussions that are happening in the community (you can check them here and feel free to open one or contribute to an active one) and I am excited to see how much we have to look forward in 2023.

A month ago we open sourced Score. The community response has been really great so far (just over 1k stars in 4 weeks) and we got many questions thrown at us:

Hi all, I am Giulia, Community Manager and part of the team that launched Score.dev a week ago. My team and I believe that developers shouldn’t fight with tooling and advocate for a workload-centric approach to development. We’re on a mission to reduce cognitive load on developers, minimize configuration drift and mismanagement, and improve the developer experience. Want to join us as a contributor? Read the official announcement to learn more. Or check us out on GitHub!

Last week we released score-spec and I asked a few communities for feedback on how you manage configuration between multiple environments and a lot of you (thanks!) came up with some answers and more questions. Here I wanted to list the pros and cons, in my humble opinion, of the top approaches suggested. Feel free to add yours as well!

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