[Justsignedup]

Reactor model. Nice. Very nice. So real ruby multithreading at last.

Okay time to upgrade to latest rails and wait for the multithreaded rails release. :P

[sosodev]

I suspect it will be quite a while before we see Ractor being used in Rails. Ractor is very strict about data isolation to prevent race conditions and existing code will need significant refactoring.

[joelbluminator]

I don't understand what you mean by "real multithreading". What I understand from Ractor is that it makes it safer to write concurrent code (e.g there are constructs that keep you from mutating shared data). But there is still a global VM lock, or is that gone in Ractor?

[lucraft]

I believe the VM lock is now per-ractor, so no longer global no. Then there are constraints on what can be shared between ractors to ensure safety.

[dorianmariefr]

puma, the default webserver when using rails, is most-likely what would be using ractors

[sosodev]

Here's schneems, a Puma maintainer, talking about Ractor, Rails, and Puma https://old.reddit.com/r/ruby/comments/ivasiq/we_made_puma_f...

[jacobvosmaer]

>The biggest issue with ractor support as it stands today would really be getting ALL the libraries any given app uses to support the ractor design.

I wonder if this will create a chicken-egg situation. Without significant Ractor adoption it will be hard to get libraries to adapt. Without essential pieces like Puma supporting (and benefiting from) Ractor there is less reason to for apps to use Ractor.

I am reminded of the difficulties faced by Rubinius, which if I understand correctly, was hampered by too many MRI-compatible libraries not working to get people to switch.

[sosodev]

I imagine getting wide support for Ractor will be easier than Rubinius and other async Ruby attempts since it’s actually part of the core language.