3 ms·

Guid package generates guids/uuids. Your linked package generates variable length strings. These are different usecases (oh, and your benchmarks are inferior to

Guid package generates guids/uuids. Your linked package generates variable length strings. These are different usecases (oh, and your benchmarks are inferior to https://github.com/sdrapkin/randstring https://github.com/sdrapkin/randstring). Nothing to argue about.

shakna 1y ago
But this doesn't generate guid/uuids? It generates random bytes.
- sdrapkin 1y ago
  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.
imiric 1y ago
No need to argue. You just haven't addressed the point that a fast UUID generator is a security risk. I don't care about benchmarks. And in most use cases where I'd need a UUID, I'd usually want the string representation of it.
- sdrapkin 1y ago
  Fast guid/uuid generators are NOT a security risk. You want such generators to be as fast as possible, without compromising cryptographic strength.

shakna 1y ago

But this doesn't generate guid/uuids? It generates random bytes.

sdrapkin 1y ago
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.

imiric 1y ago

No need to argue. You just haven't addressed the point that a fast UUID generator is a security risk. I don't care about benchmarks. And in most use cases where I'd need a UUID, I'd usually want the string representation of it.

sdrapkin 1y ago
Fast guid/uuid generators are NOT a security risk. You want such generators to be as fast as possible, without compromising cryptographic strength.