3 ms·

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

80 points by ksec 2mo ago

ksec 2mo ago
It will be interesting to see the Ruby Rails direction on ractor vs Fiber. Shopify is testing on Falcon / Fiber for production already. Edit: Turns out they are working on Ractor as well ( https://railsatscale.com/2026-08-11-ractors-on-rails/ https://railsatscale.com/2026-08-11-ractors-on-rails/)
- shevy-java 2mo ago
  Is it interesting? I think the whole debate of "Ractor versus Fiber" originates from the prior problem of ruby trying to overcome the GIL. Ractor is a more extensive solution here rather than Fibers. What shopify does or does not do, IMO, should not be of any concern. I'd rather like to have a ruby variant where shopify does not pull any strings. I think your assessment is incorrect here, though. There is not really a "Ractor versus Fiber". To me it is more a question of namespaces versus Ractor, since that has indirectly to do with per-process isolation (Ractor is kind of the attempt to do that for all of the thread/GIL, but personally I think Ractors should not even exist in the first place at all, since to me that is just a work around, even if that description is also not completely correct either; I also don't think Fibers should exist, everything should go back to threads+processes only. No need to make ruby any more complicated than it already is, when it comes to multiprocessors).
  - ksec 2mo ago
    It is interesting not in terms of its technical capabilities or merit ( or lack of ), but what Rails will default into. Apart from Minitest, defaults in rails tends to have a large impact on its ecosystem. ( Not that I like it either, but in most cases that is the. Way it is )
shevy-java 2mo ago
https://yaroslav.io/opensource/kino https://yaroslav.io/opensource/kino Where is the documentation? I am sorry but this is really a problem in the ruby world. Everyone sees how much ruby is struggling right now, yet key problems, such as documentation, are not a focus. Look at rack, ruby-wasm, ruby-opal and many other projects. Too many ruby developers hate documentation. There are a few exceptions (Jeremy Evans projects typically have a strong focus on documentation, for instance), but by and large I don't understand why documentation is always an afterthought of most projects. If you look at the github page at https://github.com/yaroslav/kino https://github.com/yaroslav/kino, and search for the keyword "documentation", you get zero results. I would instead have expected at the least a link with extensive documentation, both project-internally, but more importantly, via specific examples, a useful FAQ, and most importantly a kind of extensive "how to use this". Even ruby on rails, by the way, understood that this is important, and they have a tutorial (how useful that is, is another topic, but at the least rails people understand that documentation is important; see here: https://guides.rubyonrails.org/getting_started.html https://guides.rubyonrails.org/getting_started.html) Edit: They have on directory called doc/ here at: https://github.com/yaroslav/kino/tree/main/doc https://github.com/yaroslav/kino/tree/main/doc But have a look at this: "Almost all content here is written by agents (Claude Code or Codex)." When a project is too lazy to write documentation by a human, and instead resorts to AI slop spam, then why should real human use this? I don't get it. Is the ruby world nuts now? All that pointless AI slop spam? A lot of it is unreadable to me, it makes no sense. I am noticing this with Hiroshi Shibata, before he had difficulty with english, now he writes perfect english - aka AI slop. And the generated words STILL MAKE NO REAL SENSE. I read a lot of it and it is gibberish nonsense. It is like babelfish, only slightly improved. Mankind is actively getting dumber now.
- digitaltrees 2mo ago
  Ruby code is readable. So some of the documentation in say, Java, isn’t as necessary.
  - paulryanrogers 2mo ago
    Debatable. I always found languages without parentheses inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting.
    - bluerooibos 2mo ago
      > inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting. I'm confident that you're either an outlier or have simply come across a terribly written or badly formatted Ruby codebase - considering Ruby (and Rails which followed the same principles) was created with the purpose of being highly readable (made for humans [1]). What is advanced IDE highlighting? Do you mean.. colours? And memorising methods - huh? I really struggle to see how you can't tell which lines here are methods - https://gist.github.com/davidlares/5d136fa54572ad98e711e36843dc4410 https://gist.github.com/davidlares/5d136fa54572ad98e711e3684... [1] https://news.ycombinator.com/item?id=22090358 https://news.ycombinator.com/item?id=22090358
      - paulryanrogers 2mo ago
        I don't mean method definitions. I mean method invocations.
        bluerooibos 2mo ago
        I see. In almost 10 years of using Ruby I can't say that ever bothered me.
        pmontra 2mo ago
        The guidelines I remember are no parentheses for DSLs, e.g. the Rails validation methods or the associations, and parentheses for the other methods.
Aldipower 2mo ago
High-performance and Ruby. An oxymoron. SCNR
- digitaltrees 2mo ago
  Not if the performance is joy and feature velocity.
  - Aldipower 2mo ago
    Fair enough. :-)
baggy_trough 2mo ago
Excited to see the recent momentum for Ractor in Rails as well as base Ruby!
flossly 2mo ago
I've such fond memories of Ruby. Just moved to Kotlin since and it feels like a Ruby-with-types-and-Java-interop. Both Ruby and Kotlin are OO-first but FP-ready. Both are very expressive. Interesting enough the JVM is so much further ahead that my HTTP-server is implemented "in JVM" (the built in "Sun" HTTP server is good enough for production use in our case). Where as in Ruby land there was (and is) always a native HTTP-server in the dependencies of a production app.
- drzaiusx11 2mo ago
  JRuby is another option for Java interop, although inline types are sorely missed still. TRuby is an interesting project in that regard though
csneeky 2mo ago
Another hitch for people to tie their boats to a sinking ship.
deleted 2mo ago
[deleted]
deleted 2mo ago
[deleted]

80 points by ksec 2mo ago

ksec 2mo ago

It will be interesting to see the Ruby Rails direction on ractor vs Fiber. Shopify is testing on Falcon / Fiber for production already. Edit: Turns out they are working on Ractor as well ( https://railsatscale.com/2026-08-11-ractors-on-rails/ https://railsatscale.com/2026-08-11-ractors-on-rails/)

shevy-java 2mo ago
Is it interesting? I think the whole debate of "Ractor versus Fiber" originates from the prior problem of ruby trying to overcome the GIL. Ractor is a more extensive solution here rather than Fibers. What shopify does or does not do, IMO, should not be of any concern. I'd rather like to have a ruby variant where shopify does not pull any strings. I think your assessment is incorrect here, though. There is not really a "Ractor versus Fiber". To me it is more a question of namespaces versus Ractor, since that has indirectly to do with per-process isolation (Ractor is kind of the attempt to do that for all of the thread/GIL, but personally I think Ractors should not even exist in the first place at all, since to me that is just a work around, even if that description is also not completely correct either; I also don't think Fibers should exist, everything should go back to threads+processes only. No need to make ruby any more complicated than it already is, when it comes to multiprocessors).
- ksec 2mo ago
  It is interesting not in terms of its technical capabilities or merit ( or lack of ), but what Rails will default into. Apart from Minitest, defaults in rails tends to have a large impact on its ecosystem. ( Not that I like it either, but in most cases that is the. Way it is )

shevy-java 2mo ago

https://yaroslav.io/opensource/kino https://yaroslav.io/opensource/kino Where is the documentation? I am sorry but this is really a problem in the ruby world. Everyone sees how much ruby is struggling right now, yet key problems, such as documentation, are not a focus. Look at rack, ruby-wasm, ruby-opal and many other projects. Too many ruby developers hate documentation. There are a few exceptions (Jeremy Evans projects typically have a strong focus on documentation, for instance), but by and large I don't understand why documentation is always an afterthought of most projects. If you look at the github page at https://github.com/yaroslav/kino https://github.com/yaroslav/kino, and search for the keyword "documentation", you get zero results. I would instead have expected at the least a link with extensive documentation, both project-internally, but more importantly, via specific examples, a useful FAQ, and most importantly a kind of extensive "how to use this". Even ruby on rails, by the way, understood that this is important, and they have a tutorial (how useful that is, is another topic, but at the least rails people understand that documentation is important; see here: https://guides.rubyonrails.org/getting_started.html https://guides.rubyonrails.org/getting_started.html) Edit: They have on directory called doc/ here at: https://github.com/yaroslav/kino/tree/main/doc https://github.com/yaroslav/kino/tree/main/doc But have a look at this: "Almost all content here is written by agents (Claude Code or Codex)." When a project is too lazy to write documentation by a human, and instead resorts to AI slop spam, then why should real human use this? I don't get it. Is the ruby world nuts now? All that pointless AI slop spam? A lot of it is unreadable to me, it makes no sense. I am noticing this with Hiroshi Shibata, before he had difficulty with english, now he writes perfect english - aka AI slop. And the generated words STILL MAKE NO REAL SENSE. I read a lot of it and it is gibberish nonsense. It is like babelfish, only slightly improved. Mankind is actively getting dumber now.

digitaltrees 2mo ago
Ruby code is readable. So some of the documentation in say, Java, isn’t as necessary.
- paulryanrogers 2mo ago
  Debatable. I always found languages without parentheses inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting.
  - bluerooibos 2mo ago
    > inscrutable. To distinguish methods you have to have all method signatures memorized or rely on an advanced IDE with highlighting. I'm confident that you're either an outlier or have simply come across a terribly written or badly formatted Ruby codebase - considering Ruby (and Rails which followed the same principles) was created with the purpose of being highly readable (made for humans [1]). What is advanced IDE highlighting? Do you mean.. colours? And memorising methods - huh? I really struggle to see how you can't tell which lines here are methods - https://gist.github.com/davidlares/5d136fa54572ad98e711e36843dc4410 https://gist.github.com/davidlares/5d136fa54572ad98e711e3684... [1] https://news.ycombinator.com/item?id=22090358 https://news.ycombinator.com/item?id=22090358
    - paulryanrogers 2mo ago
      I don't mean method definitions. I mean method invocations.
      - bluerooibos 2mo ago
        I see. In almost 10 years of using Ruby I can't say that ever bothered me.
      - pmontra 2mo ago
        The guidelines I remember are no parentheses for DSLs, e.g. the Rails validation methods or the associations, and parentheses for the other methods.

Aldipower 2mo ago

High-performance and Ruby. An oxymoron. SCNR

digitaltrees 2mo ago
Not if the performance is joy and feature velocity.
- Aldipower 2mo ago
  Fair enough. :-)

baggy_trough 2mo ago

Excited to see the recent momentum for Ractor in Rails as well as base Ruby!

flossly 2mo ago

I've such fond memories of Ruby. Just moved to Kotlin since and it feels like a Ruby-with-types-and-Java-interop. Both Ruby and Kotlin are OO-first but FP-ready. Both are very expressive. Interesting enough the JVM is so much further ahead that my HTTP-server is implemented "in JVM" (the built in "Sun" HTTP server is good enough for production use in our case). Where as in Ruby land there was (and is) always a native HTTP-server in the dependencies of a production app.

drzaiusx11 2mo ago
JRuby is another option for Java interop, although inline types are sorely missed still. TRuby is an interesting project in that regard though

csneeky 2mo ago

Another hitch for people to tie their boats to a sinking ship.

deleted 2mo ago

[deleted]

deleted 2mo ago

[deleted]