15/8/2026, 3:14:00 pm
A few months ago, I wrote about a side project that had gotten slightly out of hand. First I wanted to build a web framework in Rust. Then I wanted to build the HTTP layer underneath it. Then, after spending enough time fighting with the assumptions baked into the Async Rust ecosystem, I decided the entirely reasonable thing to do was to build an async runtime as well, because why not.
That runtime was Karmaio. And, somehow, it actually exists now.
Today I’m releasing the first public alpha of Karmaio. You can find it on GitHub if you want to go straight to the code.
Before we dig into the boring details, I should probably get this out of the way.
This is an alpha release.
Not the modern SaaS definition of alpha where the product has already been running in production for three years and “alpha” means the marketing team hasn’t made a launch video yet. No no, this is an actual alpha release.
The APIs are unstable. They can change substantially between releases. Internals will change. There are almost certainly bugs. Entire ideas that look good right now might turn out to be terrible once people actually try to use them. It might not even work properly for you as it exists today.
So please don’t replace Tokio in the payment processing system in your big production app with Karmaio and then send me an angry email. At least not yet. Maybe next year.
The point of this release is to finally get Karmaio out of the purely experimental phase where I am the only person using it, breaking it and deciding whether its APIs make sense. There is now enough of a runtime here that other people can poke at it too.
And that is where things start getting interesting.
When I first announced karmaio, I described three things I wanted from it:
Those ideas have survived contact with the implementation surprisingly well.
There is obviously far more code now than when Karmaio was just some notes and half-formed ideas in my head, but I am quite happy with where the architecture has ended up (after at-least sixteen refactors in the last four months).
Async runtimes sit at an awkward layer, especially in a zero cost abstraction language like Rust. They have to expose something pleasant enough that normal Rust code can actually use them while hiding a fairly ridiculous amount of machinery underneath - tasks, scheduling, wakeups, timers, I/O operations, kernel interfaces and all the fun ownership problems that appear when those things meet each other.
It is very easy for that machinery to leak upwards. Enough posts have been written about the Send + Sync madness (including from me) and cancellation semantics and that infamous “What color is your function?” essay.
My goal with Karmaio has been to keep the public side of the runtime relatively straightforward while keeping the internals explicit enough that I can still open a file six months later and understand what the hell I was thinking. I think I’ve managed that reasonably well.
Future me is of course free to disagree. Present me is already starting to disagree on some things.
The part I’m particularly excited about is the I/O architecture.
karmaio is built around Linux io_uring as it’s primary IO driver, and instead of treating it purely as a faster replacement for older readiness-based APIs, I’ve tried to design the runtime around what modern io_uring can actually do.
That includes a fun little feature called multishot I/O.
With traditional one-shot operations, an operation completes and userspace has to submit another operation if it wants to wait for the next event. For ex, you have to use the accept syscall every time you want to accept a new request on the socket. Multishot operations allow one submission to produce multiple completions - io_uring supports this for operations such as accept and receive. To extend our example, you call the accept operations once and kernel will keep sending you new connections automatically as they come in. No need for expensive syscalls every time.
That sounds like a fairly small implementation detail but requires some changes in the standard IO interfaces. Once you start designing around these primitives instead of trying to make them look exactly like the interfaces that came before them, some interesting possibilities open up.
And so far, I really like where that has taken the runtime.
When I originally started building my web framework, my big idea was simply to use Monoio instead of Tokio. That was it. Use an existing thread-per-core runtime, avoid imposing Send + Sync everywhere, build an HTTP library on top of it and get back to the actual web framework.
It was nice and simple. Then I started looking deeper into how async runtimes actually worked. And eventually the obvious solution to “I would like to build a web framework” became “first I will implement an asynchronous runtime.”
Perfectly normal developer led project management of course. Which developer doesn’t want to go down this rabbit hole? Sure, you might say that you don’t want to rewrite everything and give valid business reasons, but deep down inside you want to do it.
Still, I’m glad I took the detour. I started this whole thing because I wanted an excuse to get back into systems programming and understand the layers of software I had spent years simply building on top of, and Karmaio has definitely delivered on that.
Schedulers, wakers, futures, memory layouts, kernel interfaces, lock-free structures, I/O lifetimes - there have been plenty of moments where I have stared at the screen wondering why I voluntarily decided to learn any of this.
And then eventually something clicks, the design gets a little cleaner, a benchmark gets a little faster, there’s a dopamine hit and I remember exactly why. This has been the most fun I’ve had programming in years.
Which brings me to the actual reason for making this release public at this stage.
I want people to try karmaio.
Not necessarily to build production applications with it. Again: this is an alpha release. Please do not put your payment processing layer on it yet.
But clone it. Read it. Write some code against it. Build a small TCP server. See what APIs feel weird. See what documentation makes no sense. Find the assumptions I’ve made because I’ve been staring at the same codebase for too long with Zeiss lenses and got tunnel vision.
And if you’re working on a project where you think karmaio might eventually be useful, I especially want to hear from you.
One of the dangers of building something like a runtime in isolation is that you can end up constructing a beautifully designed solution to the exact set of problems you personally happened to encounter.
If you look at karmaio and think:
This would be useful for my project, except…
I want to know what comes after that except. Open an issue. Start a discussion. Send me a message. Tell me why an API is annoying. Tell me what primitive is missing. Tell me what would prevent you from actually building something on top of it.
I can’t promise I’ll agree with every suggestion (where would the fun be in that and I have watched too many Steve Jobs videos in my formative years to think like that now) but having other people put pressure on the design is exactly what the project needs at this point.
You might remember that the async runtime was never actually the end goal. The goal was a web framework, which turned into a http library, which turned into an async runtime.
From the natural order of things, the next step is the http library on top. That’s coming soon. You might even spot the code in the wild before the announcement post ;)
Releasing an alpha feels like a milestone, but Karmaio is nowhere near finished.
There are APIs I already suspect I’ll redesign, especially when I build the http library on top. There are features I want to properly experiment with, especially the multishot IO. There are undoubtedly edge cases waiting patiently to ruin my day. Async Rust itself is still moving, and io_uring keeps gaining capabilities that are worth exploring.
But this is the first point where Karmaio feels less like my experiment and more like something that could potentially become useful to other people. That makes it worth putting a version number on it and throwing it over the wall.
Maybe the architecture holds up. Maybe people try it and expose some fundamental flaw I’ve completely missed. Maybe six months from now I look back at this release and wonder why I decided to do this in the first place.
For now, though, karmaio is real, it runs (probably), and you can finally try it.
Go break it. And fix it and send me the git patches as well so I can go back to shooting ships in Black Flag.
⚙️ Karmaio is available as a cargo package on Crates.io and the sources are available on GitHub .