Today I hit the “release” button on v1.0.0 of Quamina (introduction here), a fast open-source pattern-matching library in Go. Gotta keep doing some coding to keep me honest! The purpose of today’s piece is to provide a snapshot status report and record a few technology gripes just to get them off my chest; sharing is caring.
I built Quamina v0.1.0; since then, it’s had help from others. Thanks especially to Jamie, Micha, and Yosi. I peeked back in history and the first project check-in was January 24, 2022, so that’s a year and a day from idea to stability. Too slow! I’d be mad if Quamina weren’t a hobby. People who are interested in Event-Driven software and/or high-performance Go might find a trip through my Quamina Diary posts instructive.
What does “v1.0.0” mean? · That we think it’s well-enough tested, that there’s enough there to be useful, and that we promise to change the APIs only additively.
Recent news · The biggest Quamina-related news was AWS’s release of AWS Event Ruler (“Ruler” for short), a similar event-filtering library written in Java that I bootstrapped while at AWS. Thanks to Usman and Shawn and especially Rishi for getting the open-sourcing done; I suspect this will end up being heavily used in the community.
The intent is that Java and Quamina should be compatible. At the moment, Ruler supports more pattern flavors, so Quamina needs to catch up. On the other hand, Quamina is (at least on a few common Patterns) quite a bit faster.
Checklist · Here are the things we did to make Quamina ready for v1.0.0:
Yosi made Quamina much smarter about not looking at parts of events that can’t match any Patterns. You don’t get speedups for every Pattern combination, but you often get dramatic results.
Micha did a mountain of work getting our CI/CD sorted out, fighting stupid GitHub problems, keeping me from doing stupid Git things and helping me recover when I did them anyhow.
Behind the BigCo firewall, I’d never taken a serious look at GitHub’s CI/CD/release tooling — it’d be fair to say I’ve been a bit behind the times on that stuff — so this was super-educational for me.
Micha and I figured out how to give Quamina a vanity-domain home, so Quamina’s import is now
quamina.net/go/quamina. This is promoted as a best practice and most people are too polite to clarify that it’s
a declaration of independence from GitHub, in case they go sour.
Thanks also to my wife Lauren for setting up
quamina.net on her basic hosting provider.
I adapted a couple of Ruler’s unit tests; useful for making sure we’re compatible, for comparing performance, and one of them even snagged an un-caught bug.
I made a pass over the code, killed a bunch of TODOs and bad comment grammar, and wired in a couple easy optimizations.
Did I mention “fast”? · All this whittling away and in particular Yosi’s work now have Quamina processing certain common event-matching tasks at way over 1.5 million Events/sec on my mouldy old Intel MacBook Pro. Yow!
Next steps · The next wave of work is mostly straightforward: Making Quamina more Ruler-compatible by adding lots of new patterns like monocase matching, numeric expressions, and eventually full wild-carding.
Also, there’s a lingering bug where if you add too many of Quamina’s “shellstyle” Patterns, the size of the finite automaton explodes in a stupid way — it still works, just burns a lot of memory — that annoys the hell out of me and will be hard to debug. But I will.
Gripe: GitHub commit signing · What a great idea! You can get people to sign their commits with a public key they upload, which makes paranoids like me happy. Then you can turn on branch-protection to allow only signed commits.
But in practice, it’s pretty useless, because the CI bots like Dependabot don’t sign commits. GitHub doesn’t even sign when you ask it to bring a slightly-out-of-date PR into sync with the current repo state. Blecch.
Gripe: Git generally · In all those years at Google and Amazon, I used git but both places wrapped it in so much automation that you never really needed anything more than add, commit, and push; damn few options required on any of them. Being generally lazy, I never bothered to learn more than the bare minimum.
Out there in the wilder world of GitHub, you have to know a whole lot more and, while I admire Git’s power, flexibility, and performance, I have to say I loathe the experience of using it. The learning curve is horrible. And the syntax… consider:
git log main^..HEAD # huh?!
Blecch. I just don’t think it needs to be as hard as it is.
Anyhow, thanks once again to Micha for talking me through this weirdness, and I heartily recommend his blog Git rebase, squash...oh my!, just bulging with straightforward explanations and how-to recipes.
Hobbyist · An open-source project makes for a nice hobby. I recommend it, particularly for us old folks.