Using Ractors and Making Ractors Usable

Enough Fibonacci functions! It’s time for Ractors to work a real job. Join me in building a Rack server with Ractors. We’ll solve real-world problems like worker pooling, async programming, and sharing global objects across Ractors (gasp). In the process, we’ll discuss where Ractors need to go next.

Ractor is an ambitious feature introduced with Ruby 3.0 enabling truly parallel execution on CRuby. Adoption of Ractors has been somewhat slow, however, because Ractors are not a drop-in replacement for previous concurrency abstractions. In fact, they require a different architecture altogether. In this talk, we’ll walk through the process of building a project using Ractors through the example of a Ractor-based & Rack-compatible web server. We’ll look at using Ractors with - existing design patterns - novel design patterns - Ractor-unfriendly patterns. Simultaneously, we’ll evaluate Ractors as a language feature; that is, examine its stability, reliability, and coherence with other concurrency abstractions like Fibers and Threads. The talk aims to lend insight into how you can use Ractors in your own, non-trivial project and leave with ideas on how you can contribute to the improvement of Ractors as a language feature.

Bio

I am a core member of a research team working on parallel computing (not in Ruby), and I’d love to share some parallel design insights I learned in my team with the Ruby community. I also experimented very heavily with Ractors, which led to my finding of over 5 bugs in Ractors alone, with one potential CVE in the drafts with a security researcher. Some non-Ractor design patterns I will cover in the talk are worker pools, event loops, asynchronous connection handling, and incorporating singletons (e.g. Loggers). I will also cover some critical bugs in Ractors that have not been patched yet and how to circumvent them.