3 ms·

Guid/uuid is defined as a 16-byte structure. Are you questioning the “byte” part, or the “random” part?

shakna 1y ago
No, its defined to a series of specifications. [0] Ones that define an underlying structure, in bits. You have a 16byte random string. Thats great. But it is not a UUID. [0] https://www.rfc-editor.org/rfc/rfc9562.html https://www.rfc-editor.org/rfc/rfc9562.html > The UUID format is 16 octets (128 bits) in size; the variant bits in conjunction with the version bits described in the next sections determine finer structure.
- sdrapkin 1y ago
  No, Guid/uuids are defined as 128-bit labels used to uniquely identify objects in computer systems. This 128-bit/16-byte definition predates any RFCs that one may or may not choose to implement. I'm obviously aware of RFC 9562, and nowhere in the Guid library do I claim implementation of it. RFC 9562 is a choice, and one that should not be made blindly, or for you. It all starts with 16 random bytes. Google's uuid starts that way, and virtually every other Guid/uuid implementation. Then, on top of that building block, one may tweak additional non-random bits if the usecase truly requires it. If it does - you can do it quickly and cheaply on top of 16 random bytes. If the usecase does not require it (99% of cases), you're better off with the foundational 16 random bytes. The perspective of "your 16 random bytes do not implement RFC 9562 - BAD, BAD!" is very myopic. But if wasting bits on versions and variants is something that helps someone sleep better - they can easily and cheaply achieve that with a couple of bit ops. RFC 9562 robs developers of that choice.
  - shakna 1y ago
    Ok... But if you want to ignore the last twenty years, you should probably pick another name, because it has been used a particular way for two decades. If you want "more choice" - use a name unbound by a tradition old enough to drink.

No, its defined to a series of specifications. [0] Ones that define an underlying structure, in bits. You have a 16byte random string. Thats great. But it is not a UUID. [0] https://www.rfc-editor.org/rfc/rfc9562.html https://www.rfc-editor.org/rfc/rfc9562.html > The UUID format is 16 octets (128 bits) in size; the variant bits in conjunction with the version bits described in the next sections determine finer structure.

sdrapkin 1y ago
No, Guid/uuids are defined as 128-bit labels used to uniquely identify objects in computer systems. This 128-bit/16-byte definition predates any RFCs that one may or may not choose to implement. I'm obviously aware of RFC 9562, and nowhere in the Guid library do I claim implementation of it. RFC 9562 is a choice, and one that should not be made blindly, or for you. It all starts with 16 random bytes. Google's uuid starts that way, and virtually every other Guid/uuid implementation. Then, on top of that building block, one may tweak additional non-random bits if the usecase truly requires it. If it does - you can do it quickly and cheaply on top of 16 random bytes. If the usecase does not require it (99% of cases), you're better off with the foundational 16 random bytes. The perspective of "your 16 random bytes do not implement RFC 9562 - BAD, BAD!" is very myopic. But if wasting bits on versions and variants is something that helps someone sleep better - they can easily and cheaply achieve that with a couple of bit ops. RFC 9562 robs developers of that choice.
- shakna 1y ago
  Ok... But if you want to ignore the last twenty years, you should probably pick another name, because it has been used a particular way for two decades. If you want "more choice" - use a name unbound by a tradition old enough to drink.