Good article on ruby fibers/threads/ractors, i think i understand it a little better now. I didn't know there is always a current fiber, thread, and reactor for ruby code that is ran. But I don't if i fully grok how to think about them yet - it seems like the goal is I shouldn't have to to a degree.<p>The onion was interesting to see how they're all a family, but I think the explanation was not clear. Helpful to think of everything as an onion though, but it gets lost for me with layers that are parallel/concurrent.<p>> Once we exceed the ability to parallelize, we are concurrent in the same way as Threads and Fibers! This model allows our units of concurrency adapt to the environment - when cores are available they can run in parallel, and when cores are not available they can swap between each other, transparently to the program itself. Every program eventually becomes concurrent as it scales, at least for CPU-bound processing.<p>This is interesting and i KINDA get it, but the graphic shows ractors -> cores even though ractors have no parallel to the OS as proccess/threads do, so a bit confused by that and how the onion is unfolding here.<p>Overall I'd say there's a lot of cool ruby things to learn from this and i wish i read more insightful articles like this more often, but i do wish the writing was more polished, focused, and clear so it's better digested.