Performance: when your app *IS* fully Ractor-shareable, on AWS (Ruby 4.0 + YJIT) vs a Puma fork cluster:
• ~15× less RAM — 80 MB vs 1,256 MB
• +32% on pure CPU
• 1.5–2× on I/O-light routes
Instead of forking a process per core (a full app copy each), Kino runs your Rack app on every core in one small process. Rust (tokio/hyper) owns the network; parallel Ractors run your Ruby.
Rails can't run on Ractors though, blocked upstream. Rails holds global mutable state a non-main Ractor can't touch → Ractor::IsolationError. Most gems aren't Ractor-safe yet either.
So is Kino useless for Rails? Well, Rails runs on Kino today in :threaded mode — parallel for I/O, GVL-serialized for CPU; you just don't get the numbers above.
Kino also ships `kino --check` to find Ractor incompatibilities for you.
Rubyists who experiment with Ractors, put them to work! Meet Kino, an experimental performant Ractor web server (with a threading fallback).
github.com/yaroslav/kino
Note that Ractors are experimental, and so is this server. Rails cannot run on Ractors yet, but it will, sometime in the future. 🧵
Yaroslav Markin
I am finally a Ruby contributor, I guess. In the next version, Array#join—most of the time—would work up to 2.5x faster.
github.com/ruby/ruby/pu...
