Show HN: Go library for concise, unambiguous and URL-safe UUIDs | Hacker News Reader

Show HN: Go library for concise, unambiguous and URL-safe UUIDs

github.com

50 pointsSpiritus14 comments

Ran it through an app I maintain, Go Report Card, and it got an A+ grade: http://goreportcard.com/report/renstrom/shortuuid

I'm actually pretty surprised, as I do this quite often and it's rare that something gets 100% across the board on the first try. Not that it's necessarily difficult, but I find people normally don't use all 3 of "gofmt -s", "golint", and "go vet". Anyway, nicely done.

I use gometalinter which runs it through a whole suite of linters.

The goals of unambiguous and concise are at odds, and this format (well, the defaults) errs on the side of shorter.

To lessen ambiguity even more, there's Crockford Encoding[0]. Results in longer strings, but there's no case distinction, and the similar looking characters decode the same. Looks like you can get mostly Crockford Encoding using this library by changing the character set (which is why said "the defaults" above). The check digit in Crockford Encoding is a huge win for when these are dictated/transcribed, but may need to be URL-encoded.

[0] http://www.crockford.com/wrmg/base32.html

That's interesting. I will definitely see if I can incorporate it somehow, even if it's just a note in the README.

My Go is rusty, but this look a little error prone:

    // Note that this will create a new UUID each time its .String() method
    // is invoked.
    fmt.Printf("%s", u)  // Cekw67uyMpBGZLRP2HFVbe
    fmt.Printf("%s", u)  // 4pUYNRFHTG3YVgThPZvCgC

Just imagine an user using u directly instead of assigning to a var:

    token := "secret" + u
    othertoken := "app" + u

Author here. Yes, this is indeed a terrible idea! Will definitely fix it.

Fixed in https://github.com/renstrom/shortuuid/commit/847debec9c7c091...

Yes, this is a terrible idea - it violates referential transparency, which is a property that is always worth working towards, imo. I can't think of a reason to justify breaking that property in this scenario.

That can be mostly avoided by naming things correctly.

uuid_generator would be far less likely to be misused than u.

For whatever reason, however, descriptive variables are not very popular in the Go community.

Sure, but .String() wouldn't be a good method for uuid_generator to use to generate a new UUID--String() should be a string representation of the thing; it says "this is a string of me". Which is where the confusion would come from.

As mentioned in the README, it's heavily based on the Python version[1].

[1] https://github.com/stochastic-technologies/shortuuid

I thought UUIDs had to be 128 bits, such as "de305d54-75b4-431b-adb2-eb6b9e546014" (32 x 4-bit characters, not counting hypens). How is "ajLWxEodc6CmQLHADuKVwD" a UUID?

"de305d54-75b4-431b-adb2-eb6b9e546014" is simply an encoding of a 128 bit number. This standard hex UUID representation requires 8 bits/character * 36 characters == 288 bytes == 2304 bits. This encoding only requires 22 characters or 1408 bytes, almost half the size.

base 57

Reply on news.ycombinator.com