Excellent points in the article about "top" (booting off top-level workers in Ractors) versus "bottom" (parallelization at the edges of the code where not as mu

Excellent points in the article about "top" (booting off top-level workers in Ractors) versus "bottom" (parallelization at the edges of the code where not as much state needs to be shared) cases, with the top likely to take more time to widely manifest as more Ruby code becomes Ractor friendly. I know Ractors are still quite new, but I'm curious to see how much luck people will have in migrating existing parallel code over to them. Relying on a lot of shared state is going be the major blocker. Just on a token reading of the docs [1], it looks like you should be able to share quite a lot of state still as long as you're able to freeze it all into immutability. You could then use message passing around the edges where immutability is a non-starter. But this is probably easier said than done. --- [1] https://docs.ruby-lang.org/en/3.0.0/Ractor.html https://docs.ruby-lang.org/en/3.0.0/Ractor.html