uuid VS go-nanoid

https://github.com/gofrs/uuid upto v5

I use Google's UUID package a lot. But every time I refer to it in a new package, the language server picks up https://github.com/gofrs/uuid instead of https://github.com/google/uuid and then complains that the gofrs package isn't in go.mod. I assume because it's the first alphabetically (though this seems like a huge supply chain security loophole).

What makes this different than https://github.com/gofrs/uuid ?

Something to note is that all of this is still open source. Theoretically, someone can decide to fork SQLBoiler and add all the missing things, or send in a PR. A good example is that the current most popular uuid package. gofrs/uuid was forked from an unmaintained previously popular package.

You could also look at github.com/gofrs/uuid which includes support for v6 and v7 from the latest draft UUID spec. Personally I think the API for this library is nicer since the google one makes it difficult to tell what kind of UUID you are generating.

Postgres has native UUID support so don't use VARCHAR(36). Look at https://github.com/gofrs/uuid library, among others, to create uuid.

If you're using this library and are unsure what to do, a few of us maintain a fork of this library that has fixed these issues (and others): https://github.com/gofrs/uuid

Using jaevor/go-nanoid for those short IDs. With a ID length of 10 it'll take about ~17 years to have ~1% chance of collision.

With criterion benchmarking, nanoids of length 255 average about 101ns to generate, whereas in my Go implementation they take over 470ns. I know this is just benchmarking and only nanoseconds, but it's nice to have a comparison.