
My experience with Ractor was that I wanted to run various instances of whitequark/parser gem in parallel, but there were a couple of problems, for instance Ragel generated code contained something like singleton getters/setters on global modules. This made me rethink use of singleton getters/setters on global in the future, as they are very akin to what are global variables, but I didn't go as far as trying to fix Ragel to generate better code. But I also didn't like the fact, that I had to write unclean code like: call_a_method(&Ractor.make_shareable(proc do do_something )) For a Ractor to actually launch correctly. Finally, what I wanted to do, I implemented with fork. But - I agree with you in general - if you carefully deal with threads like Erlang forces you to do, nothing will go wrong. Python has recently eliminated its GIL. The GIL severely limits what you can do with Threads, it basically only allows you to accelerate IO with that (and for IO, cooperative multitasking is a much better choice anyway). On 1/21/23 23:23, Andy Maleh via ruby-talk wrote:
I’ve toyed around with Ractors, thinking they might be a Godsend for GUI apps, like those built by Glimmer DSL for LibUI (https://github.com/AndyObtiva/glimmer-dsl-libui). But, they always turned out to be more pain to use with the variable access restrictions than plain old threads, which I get for free as truly parallel in JRuby while using Glimmer DSL for SWT (https://github.com/AndyObtiva/glimmer-dsl-swt).