Question: will the nonblocking scheduler start to make Ruby concurrency competitive with e.g. Node.js and Go? Currently Ruby mostly uses heavyweight threading mechanisms that cause trouble for I/O-bound microservices.
Indeed, anyone who has used actors IRL projects it goes well beyond just isolation and message passing. That’s just the foundation which higher abstractions are built, which is why it’s still comparable to Go/CSP at this level.
I'm not sure if Ractor has any real benchmarks yet but it enables genuine parallel Ruby code that communicates through message passing without too much overhead.
Well, ruby was able to be concurrent for a while now. It has lightweight cooperative threads, it has reactor loops. The problem was/is/will be - lack of gems that support either of them.
EventMachine was a nightmare to work on and to work with, but with fibers it and some wrappers you could write some neat code. Most library were making a lot of bad assumptions - "there is a GIL and i'm running on a full thread and also wtf are threads in general, never heard of it?"
Almost no one in ruby world thought about writing a better code to make application faster, it was always about either finding a better gem or adding more application servers. Here is the closest ruby has been towards concurrency https://github.com/igrigorik/em-synchrony guess why it never took off.
Ruby 3.0 is a first step towards having libraries being aware that they are in on fiber and not thread.