Live data from Hacker News

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

github.com

131–140 of 236 posts

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

#131
post #64

Earlier quoted context omitted.

> 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 (an…

You could argue that U can be confused with V.

Fvck!

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

#132
post #88
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 F word has a U in it. Sure you could just say FVCK

[deleted]

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

#133
post #64
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 (an…

U is a fairly new letter anyway.

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

#134
post #120

A couple of suggestions: Lock down the prefix string now before it’s too late and document it. I see in Go that it’s lowercase ascii, which seems fine except for compound types (like “article-comment”). May be worth looking at allowing a single separator given that many complex projects (and ORMs) can’t avoid them. The Go implementation has no tests. This is very unit-testable. Add tests goddammit! For Go, I’d align…

Thanks for the feedback!

We have tests for the base32 encoding which is the most complicated part of the implementation (https://github.com/jetpack-io/typeid-go/blob/main/base32/bas...) but your point stands. We'll add a more rigorous test suite (particularly as the number of implementations across different languages grows, and we want to make sure all the implementations are compatible with each other)

Re: prefix, is the concern that I haven't defined the allowed character set as part of the spec?

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

#135
post #129
post #120

A couple of suggestions: Lock down the prefix string now before it’s too late and document it. I see in Go that it’s lowercase ascii, which seems fine except for compound types (like “article-comment”). May be worth looking at allowing a single separator given that many complex projects (and ORMs) can’t avoid them. The Go implementation has no tests. This is very unit-testable. Add tests goddammit! For Go, I’d align…

> Add tests goddammit! Hey, you’re pretty smart. How about you add them?

I’m by no means a test police. I’m in fact opposed to a lot of mindless testing for the sake of it. But there are places where unit tests shine, and this is one of them.

If you mean that criticism is only allowed if you are willing to commit labor, I disagree with that. I always welcome critique myself - it may be something that I’ve missed. The maintainers always has the last word. As long as there are no hidden expectations, it’s all good.

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

#136
post #56

Earlier quoted context omitted.

You can prevent any obscenity, O and 0 confusion, and I and L confusion, just by excluding vowels. If someone interprets "f4g" in an offensive way, then they have bigger issues than can be dealt with in software.

Obscenities change with language. That’s why every language has them. Even programming language have them. For instance, Basic has GOTO. /j

and javascript has type coercion

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

#137

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…

I moved to ULID because they are always lowercase and therefore case-insensitive.

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

#138
post #120

A couple of suggestions: Lock down the prefix string now before it’s too late and document it. I see in Go that it’s lowercase ascii, which seems fine except for compound types (like “article-comment”). May be worth looking at allowing a single separator given that many complex projects (and ORMs) can’t avoid them. The Go implementation has no tests. This is very unit-testable. Add tests goddammit! For Go, I’d align…

I'll write some tests for this.

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

#140

Earlier quoted context omitted.

You can prevent any obscenity, O and 0 confusion, and I and L confusion, just by excluding vowels. If someone interprets "f4g" in an offensive way, then they have bigger issues than can be dealt with in software.

The problem is not being offended per se, but having your user id accidentally become "user_123fuck567" — that's akin to having a vulgar license plate on your car's forehead. People don't appreciate how lucky they sometimes are.

Are those supposed to be user- facing though?
Post reply on HN