Printing references as strings?

True, I was kind of referring to the API contract.

These two are pretty much different wrt. randomness guarantees

:rand.bytes(16)   # If you are at OTP 24.0 or above
:crypto.strong_rand_bytes(16)   # More backwards-compatible but basically the same

…which gives you 16 random bytes, which you can then format as hex strings, or anything else you need.

Hi there, I didn’t catch the takeaway here. I think I have a similar use case. I just want a unique-ish ID to identify a particular connection to a 3rd party API. this post on SO claims that make_ref/0 is the canonical way but I’m not sure how to convert that to something like a string of numbers to use as a param for the call to the API?
I’ve used UUID and Ecto in the past but trying to understand the “usual approach” and minimized external dependencies for something that shouldn’t need those libs at this time. Any advice?

Actually yep, you are right.

Elixir and Erlang libraries mostly use binaries for storing UUID which IMHO makes most sense.

Ouch! You do gotta wonder what horrendous legacy compatibility reasons made them do that…

Even worse is django stores them in the DB as a base16 string . If you’re gonna do that, at least keep the hyphens.

True, however the fact that most libraries compare them as strings rubs me off the wrong way. I’d feel much better if UUIDs were actually treated as byte arrays and compared as such (or in Erlang/Elixir’s case, fixed-size tuples of integers). IMO that leaves some untapped performance potential on the table – even if I know it’s likely negligible it still worries me.

Much stronger than make_ref/0 (64 bits vs 122 bits, which with birthday collision will provide 10¹⁰ difference factor in possible collisions). And generating UUID can be done also outside of the BEAM, which is clearly a win for me.