In the Ruby 3 features, a lot of attention went to Ractors - a new parallelism primitive which provides what can best be described as â€śWeb Workersâ€ť - separate threads of execution with memory isolation from the spawning thread. However, there was also a release of a seemingly â€śnerdyâ€ť feature which is the FiberScheduler.
Ractors still have to prove their own (my dear friend Kir Shatrov has done some exploration into designing a Ractor-based web server) but I would like to highlight that second feature, and the concept of scheduling and reduction in general.
I strongly believe making good use of Fibers is instrumental to Ruby staying relevant for creating web applications. As a community we are in a tight squeeze now, between Go on one side and Node.js on the other side, and the concurrency story in Ruby isnâ€™t that good compared to either of the two - however we stand a measurable, substantial chance of once more getting ahead of the game. Especially considering that Python3 has chosen for the â€ścoloredâ€ť functions model with its asyncio setup. See Kirâ€™s article for an interesting perspective on this too.
See, when people talk about Ruby parallelism and concurrency usually the conversation is quickly curtailed by the first person who screams â€śBut the GIL! So there is no parallelism!â€ť and then the room falls silent. In practice the situation is much more nuanced, and gaining a better understanding of the nuances will make your Ruby programs faster, more efficient and let you use less compute. If you know where to look.