[olivierlacan]

That’s the plan with Guilds: http://www.atdot.net/~ko1/activities/2018_rubyconf2018.pdf

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.

[ioquatix]

Hi, I'm the author, I'm also a Ruby core committer, and yes I'm aware of Guilds. The are a model for parallelism and don't really affect concurrency at all. At best, they provide a 3rd option on top of processes/threads/guilds.

[olivierlacan]

That makes sense. Sorry for the assumption.

Guilds felt omitted in your post since they (should) address one of the points you make about the usability/ergonomics of existing Ruby APIs for managing non-sequential execution.

But it’s definitely a bit early to tell what Guilds will actually look like as a final product.

[ioquatix]

Guilds are just a fancy name for threads or processes at this point. What they ultimately end up being is yet to be seen :)