If you already depend on Ecto, you can call Ecto.UUID.generate for a UUID4 and get UUIDs without any further deps.

As others have noted, though, Elixir libraries tend to be pretty reliable even when not touched for a long while. This is a very nice benefit of Elixir-the-language being considered “complete” and a strong resistance to adding everything possible to standard library (e.g. UUIDs ) → the std library has the core tools (as it should) with most everything else in (usually sensibly chunked) libraries, even “very common” things like JSON or UUIDs. As such, things don’t break underneath libraries much at all, and as many libraries have pretty thin dependency chains of their own, this lends a good amount of stability that makes pulling in useful deps pretty low risk.

I don’t mind using libraries for things at all, but it seems like relying on a library for something that’s a standard thing in the industry is prone to introducing a problem later. If something in the language changes later and that library isn’t compatible and not updated often then it can lead to issues.

If you don’t care much about the format, you can use an erlang ref:

iex(2)> to_string(:erlang.ref_to_list(:erlang.make_ref()))
"#Ref<0.3277125387.4011851777.221466>"

See the doc:

Returns a unique reference. The reference is unique among connected nodes.

Basically everyone (including ecto) uses elixir_uuid. It’s effectively an “anointed package” at this point, though I wish it had typespecs

Does it? Looking at its mix.exs I don’t see such a dependency, and ecto/lib/ecot/uuid.ex implements UUID4 all on its own. Also, the uuid package has an order of magnitude more installs according to hex.pm.

That said, I doubt either of them are going away anytime soon.