Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

github.com

Post reply on HN
Print view View original

61–70 of 236 posts

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#61

Post by kibwen »

iillexial wrote: post #59

I didn't get the "type-safe" part. How would it work in Go? Let's say I have structs: type User struct { ID TypeID } type Post struct { ID TypeID } How can I ensure the correct type is used in each of the structs?

Any time you ever read a string, its type is always just going to be "string" (modulo whatever passes for a "string" in your programming language of choice). To get an actual non-string type, you'd need to parse that string, and presumably your parsing function would read the prefix and reject the string if it was passed an ID whose type doesn't match. So it's dynamically type-safe, if not statically type-safe.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#63

Post by tasn »

Xeoncross wrote: post #9

Assuming you don't need to use UUIDv7 (or any UUID's) then https://github.com/segmentio/ksuid provides a much bigger keyspace. You could just append a string prefix if you wanted to namespace, but the chance of collisions of a ksuid is many times smaller than a UUID of any version. ksuid is the best general purpose id generator with sort-able timestamps I've found and has libraries in most languages. UUID v1-7 are wa…

We maintain a couple of popular ksuid libraries[1][2] and use it, so we definitely like ksuid. Though one big issue with ksuid is that being 160bit means that it doesn't fit into native uuid types in databases (e.g. postgres), which means that they come with a performance penalty.

1: https://github.com/svix/rust-ksuid 2: https://github.com/svix/python-ksuid

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#64

Post by kibwen »

ajkjk wrote: post #4

Unrelated, but this links to "Crockford's alphabet", https://www.crockford.com/base32.html , which is a base-32 system that includes all alphanumeric characters except I and L (which are confusable with 1), O (which is confusable with 0), and U (????). The page says the reason for excluding U is "accidental obscenity'. What the heck is it talking about?

> The page says the reason for excluding U is "accidental obscenity'.

Crockford is being cheeky. To make a nice base32 alphabet out of non-confusable alphanumeric characters you only need to exclude O, I, and L. This leaves you with 33 characters still, so you need to remove one more, and it doesn't matter which one you remove, so you might as well pick an arbitrary reason for the last character that gets removed (and it's not the worst reason, if your goal is to use these as user-readable IDs, although obviously it's not even remotely bulletproof).

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#65

Post by kortex »

Does the prefix ("user_") get recorded in the DB (so every string in the column starts with the same "user_"), or does are there constraints and other clever chicanery to save those bytes in every record? Or do modern DB engines even care? Is this premature optimization?

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#66

Post by hfkwer »

iillexial wrote: post #59

I didn't get the "type-safe" part. How would it work in Go? Let's say I have structs: type User struct { ID TypeID } type Post struct { ID TypeID } How can I ensure the correct type is used in each of the structs?

This isn't about object types in any particular language.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#67

Post by leetbulb »

iillexial wrote: post #59

I didn't get the "type-safe" part. How would it work in Go? Let's say I have structs: type User struct { ID TypeID } type Post struct { ID TypeID } How can I ensure the correct type is used in each of the structs?

One way is to enforce in Marshal[0] and Unmarshal[1]

[0] https://pkg.go.dev/encoding/json#Marshaler

[1] https://pkg.go.dev/encoding/json#Unmarshaler

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#68

Post by dloreto »

TeeWEE wrote: post #62

Good, but I dont see a big advantage over UUIDv7 Anyone has some good ones?

It's based on UUIDv7 (in fact, a TypeID can be decoded into an UUIDv7). The main reasons to use TypeID over "raw" UUIDv7 are: 1) For the type safety, and 2) for the more compact string encoding.

If you don't need either of those, then UUIDv7 is the right choice.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#69

Post by zeroxfe »

iillexial wrote: post #59

I didn't get the "type-safe" part. How would it work in Go? Let's say I have structs: type User struct { ID TypeID } type Post struct { ID TypeID } How can I ensure the correct type is used in each of the structs?

It's not a language primitive. It's a data format that enables type safety in libraries or APIs (as opposed to a more opaque data format like UUIDv7.)

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#70

Post by titanomachy »

codeulike wrote: post #48
ajkjk wrote: post #4

Unrelated, but this links to "Crockford's alphabet", https://www.crockford.com/base32.html , which is a base-32 system that includes all alphanumeric characters except I and L (which are confusable with 1), O (which is confusable with 0), and U (????). The page says the reason for excluding U is "accidental obscenity'. What the heck is it talking about?

If I and O are already excluded and you also exclude U that removes a lot of potential rude looking three letter combinations like *** and *** and *** and also the four letter ones like **** and **** and the dreaded ****. Of course because you have A then **** is still a possibility but very very unlikely

Wow I didn't know HN even had obscenity filters, and I've been here for many years.

Guess that's a credit to the general civility of the community.

EDIT: It appears that other people in this thread are freely using profanity, so either your comment was targeted by automation due to the unusual density of banned words, or it's a joke that went over my head :)

Post reply on HN