|
|
|
|
|
by bhuga
2766 days ago
|
|
> We show that fibers require minimal changes to existing application code and are thus a good approach for retrofitting existing systems. I disagree that 'minimal changes to existing code' is a good goal for a Ruby parallelism solution. The large Ruby codebases I have dealt with have gigantic hacks to get around the GIL: complex fork management systems, subprocess management, crazy load-this-but-not-that systems for prefork memory management to optimize copy on write, and probably more. Parallel tasks in Ruby are a nightmare to work with. Changing existing code _should_ be a goal of any Ruby parallelism solution. If we can't get rid of this kind of cruft, what are we even doing? I still love Ruby, but I want go-style channels, not apologies for the GIL. |
|
These are the slides for Koichi Sasada’s RubyConf 2018 (last week) talk updating the community on his progress in the design and implementation of Guilds.
Surprising that the author isn’t aware of this planned CRuby feature announced in 2016. I wrote about it then: https://olivierlacan.com/posts/concurrency-in-ruby-3-with-gu...
Take this with a grain of salt of course because the design has clearly changed since then and I need to upgrade my post or do a follow-up.