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.
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.
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.