This looks like a zmk-ish solution implemented in zig for cheaper/easier devboards like the ch551/2 (and seemingly rp2040, which zmk does support), but with better ux. Better explainer in OP's post on reddit[0]:
>> Kirei is a keyboard library that you feed inputs to (which keys are pressed) and get outputs from (HID reports) ... It's not just a keyboard firmware
This looks like a repeat of the nodejs leftpad situation but this time it's for keyboard firmware.
It takes the pin changes (matrix or already decoded keys isn't clear to me) and generates the appropriate HID reports based on whether they're tapped, long pressed, shifted, etc. Not the hardest code in the world to write, but a long way from leftpad and fairly easy to miss edge cases on the first try.
Besides, what's the issue with someone writing a personal abstraction library? Java programmers commit greater crimes than this daily.
I'm struggling to understand the purpose of this library.
> Kirei is a keyboard library that you feed inputs to (which keys are pressed) and get outputs from (HID reports) ... It's not just a keyboard firmware
It’s for whatever. You feed button presses and get back a result.
But for a sample. Looks like this is what would sit on your custom keyboard and translate your key presses to something the OS you are plugged in to can use. It’s firmware.
Things like the glove80 and Voyager are pretty popular custom keyboards.
I'd say Safety, speed, and concurrency in that order. When Rust advocates talk about the borrow checker I - as a C++ developer - get interested. I can get similar safety and speed from C++ if I use modern C++, but it is too easy to drop back to the unsafe C++ even when modern C++ does the job. (You can drop to unsafe rust if you need, but it isn't as easy, and thus I would expect that Rust developers are not doing that unless they have a real need)
RAII mutex locks are a pretty good tool. But like all "modern" c++ features still require programmer diligence to use correctly. Though there are likely other tools outside a compiler error to help enforce this, like static analyzers, or even thread sanitizer to help detect possible issues on a running system.
And just like rust do little to protect against general race conditions, deadlocks, or the many other logic issues you can pretty easily hit around threading. Looking back at my experience around issues that involve threads, I suspect the vast majority of issues I see aren't data races.
Good architecture. Which isn't a c++ feature, but data races are not a big problem in my system because our architecture makes this easy. (We use qt signals/slots for cross thread messages)
It's worth noting there's a difference also between hype and genuine enjoyment/satisfaction with a product.
Look at sqlite threads - they happen here all the time, and there's cyclic periods where you'll see 2-3 a day for a week or two. This has been going on since forever, and there always seems to be someone in the comments wanting to jump on the "anti-hype train", even though after over a decade of popularity and satisfied users it might not actually be hype.
[0]: https://www.reddit.com/r/ErgoMechKeyboards/s/Dkoy7YZmWs