Kino: A high-performance Ractor web server for Ruby 4.0

Let's talk about the elephant in the room: Ruby's concurrency story has always been a tragedy. The GVL has kept the language safe and simple, but it's also turned every serious Ruby deployment into a game of "how many processes can I afford?" Puma nails it with clusters, Falcon tried fibers, and Sidekiq built an empire on threads that mostly block on I/O. Enter Ractors—the feature that was supposed to change everything when it landed in Ruby 3.0, but spent years as a curiosity for adventurous souls solving toy problems. Kino is saying: let's build a real web server on top of that. Here's the thing about Ractors that most people forget: they're not free parallelism. Objects crossing Ractor boundaries need to be shareable or marshalable, which means your request/response cycle better be cleanly separated from your app state. That's a serious architectural constraint. A web server is actually one of the more tractable use cases—stateless-ish request handling, isolated per-request data, minimal shared mutable state. So Kino's pitch makes technical sense in a way that, say, "let's run ActiveRecord queries inside Ractors" doesn't. But the devil is in the details: connection management, keep-alive, middleware that touches shared gems, and the sheer amount of C-extension code that isn't Ractor-safe yet. The Ruby 4.0 targeting is the boldest part of this move. We're talking about a server that's betting on a release that hasn't shipped, with a concurrency model that's still maturing. That's either visionary or premature, and honestly, it's probably a bit of both. The HN reception—7 points, one comment—says the community isn't sure what to make of it yet. But the author, Yaroslav, has a history of shipping interesting Ruby infrastructure, so this isn't some random weekend hack. What I'm watching for: whether Kino can actually demonstrate meaningful throughput gains over Puma in a real-world benchmark, not just a synthetic one. Ractor-based servers have been attempted before and mostly fizzled because the overhead of copying data between Ractors ate the parallelism gains. If Kino