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).
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 )
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.
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, 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)
"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.
People love taking generic engineering problems and somehow spinning them as Ruby specific issues. None of the issues you mentioned have anything to do with Ruby. They’re problems you can run into in any engineering project.
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.
> 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?
Right. And that's the issue. I want to read at a glance, without having to ask tools. Monkey patching and lack of parentheses means dropping into a new codebase is like wading into a ocean of possibilities with every file.
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/)
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).
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 )
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.
JRuby is another option for Java interop, although inline types are sorely missed still. TRuby is an interesting project in that regard though
Excited to see the recent momentum for Ractor in Rails as well as base Ruby!
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, 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)
Edit:
They have on directory called doc/ here at:
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.
People love taking generic engineering problems and somehow spinning them as Ruby specific issues. None of the issues you mentioned have anything to do with Ruby. They’re problems you can run into in any engineering project.
Ruby code is readable. So some of the documentation in say, Java, isn’t as necessary.
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.
> 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/5d136fa54572ad98e711e3684...
[1] https://news.ycombinator.com/item?id=22090358
I don't mean method definitions. I mean method invocations.
But you can literally inspect and interrogate objects. You can ask what methods exist. You can even make new methods at run time.
Right. And that's the issue. I want to read at a glance, without having to ask tools. Monkey patching and lack of parentheses means dropping into a new codebase is like wading into a ocean of possibilities with every file.
I see. In almost 10 years of using Ruby I can't say that ever bothered me.
The guidelines I remember are no parentheses for DSLs, e.g. the Rails validation methods or the associations, and parentheses for the other methods.
Another hitch for people to tie their boats to a sinking ship.
High-performance and Ruby. An oxymoron. SCNR
Not if the performance is joy and feature velocity.
Fair enough. :-)