I agree; there are entirely different ways to achieve this same goal without generics. I mentioned using a struct and including the data from the struct in the post. However, what I wanted to show within the post is how generics can make this problem easier for us.
> As boilerplate goes, if you look at it, it isn't even that much more. Interfaces can still be used to ensure that the correct methods are guaranteed to be implemented.
Yeap, we implemented many different interfaces on our ID types, and the resource type also implements a couple of interfaces (such as methods to get the Postgres type information). Unfortunately, this means we still need to create receiver methods for each of these interfaces so we can use the ID types with those underlying libraries (such as `JSON` or the `SQL` scanners) which ends up being 14 methods per resource type (and we have quite a number of resource types). We would have ended up code generating these, and generics just saved us that work.
> Underscores are too common in identifiers.
We picked underscores, as they are not included in the base32 encoding of XID. They're also safe to put in URLs without needing to perform any encoding. Our static analysis tools during CI check that all code generation has been completed and prevent the prefixes from having underscores. That means we don't need to worry about escaping as we can always unambiguously split it. However, even if your prefixes allowed underscores, you can always just split the string at the last underscore; as the XID portion of the string cannot contain it.
I'd be interested to know how you were bitten by it in the past?