For an issue tracker in Go I built a handful of reusable bits that I keep at https://code.soquee.net/ including a HOTP/TOTP multi-factor authentication library, something to "source" .env files, a library for building migration tools with Postgres and yet another HTTP router/multiplexer.

I also work on an XMPP library and related tools that has spawned other libraries for handling XML streams (basically duplicating all the functions in the io package but for XML tokens instead of bytes), a SASL authentication implementation, etc. https://mellium.im/

I have a ton more, but these are the two collections I more or less keep up to date and use the most.

To give an example of why I wasn't satisfied with the existing things, let's look at the library for migrations: prior to writing it I was using Diesel, but it didn't exist in many package repos and took literally hours to build on pretty good hardware (Rust is garbage in terms of build time, as much as I enjoy the language I almost never use it for this reason), and it had atrocious errors to the point that I'd call them bugs (I would frequently have errors that would spam the terminal with pages and pages of parenthesis, I'm sure they've fixed this, but at the time it was annoying). The various migration tools written in Go had similar problems so if I handed my nice single-binary application to someone to deploy on their own server I'd also have to hand them a zip file full of migrations and they'd have to figure out how to install a tool. Instead I wanted the binary to embed and be able to run its own migrations, so I wrote the library.

For the 2FA library it was a similar story: all the existing ones I could find had the abstraction wrong, they just did TOTP or HOTP and didn't seem to realize that they were the same thing just with a different "ticker" function. Having a simple 2FA implementation where you could create a token and pass in a custom ticker (or of course the package would have the TOTP one pre-defined) just "made sense". Also, the others I evaluated weren't tested very well. I wanted at least a handful of tests to make sure the tokens weren't going to break the next time I made an update.

Finally, for the HTTP router/multiplexer I wanted to be able to get the routes back out and match them to the URL components that matched various wildcards so that I could do easy normalization. Eg. if you had the route /u/{username string} and the URL /u/Me matched it, I wanted to be able to automatically redirect to /u/me. Most routers I tried didn't provide you enough information to do this (eg. if you had the path /user/User and you just did a naive find/replace that was more complicated than lowercasing, you'd accidentally change both when the route was /user/{string} so the first one shouldn't change). I also wanted typed route parameters to avoid the boilerplate of converting in my handlers every single time, and I wanted it to not have any ambiguous routes (eg. if I register /user/me and /user/{user string}, and the user creates a new account with the username "me" then should /user/me trigger the static route or the user page?). To fix all this I came up with the route syntax I've been using in these examples and made a muxer for it.