// the take
xid is a small Go library that generates compact, sortable 12-byte unique IDs using the same scheme as MongoDB ObjectIDs, encoded as a 20-character base32hex string. It's aimed at Go services that want short, URL-safe, time-sortable IDs (request IDs, DB primary keys) without running a coordination service like Snowflake needs.
No machine/datacenter configuration or central ID server required, which is the main thing it has over Snowflake-style generators. Generation is lock-free and fast — the benchmarks show ~32-90ns/op with a single allocation, versus UUIDv1's global lock degrading under concurrency. The base32hex encoding keeps the string sortable (k-ordered) while staying case-insensitive and URL-safe, which plain hex or base64 UUIDs don't give you for free. Binary layout is Mongo ObjectID-compatible, so it drops in cleanly if you're already on Mongo.
The README is upfront that it's not cryptographically secure — IDs are time + counter based and guessable, so don't use this for anything like password reset tokens or API keys. The machine ID is derived from the hostname and the process ID is a plain OS PID; in containers PID is frequently always 1 and short-lived containers can get reused or colliding hostnames, which narrows the collision-avoidance the Mongo-style scheme relies on more than it would on bare metal. It's effectively a finished, single-purpose library with one primary maintainer (rs) and infrequent commits — fine for something this small and stable, but there's no active development to watch if an edge case in host ID detection on some platform (the per-OS hostid files are a tell) turns out wrong for you. Unlike Snowflake, the ID layout is fixed — you can't embed a shard or tenant bit yourself, so if you need that you're building a second scheme on top rather than configuring this one.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →