Thread by @jpcamara

Over on the blue place, @tenderlove brought up some really valid points about Fibers in Ruby. I wrote up some of my thoughts over there, and figured i'd share them here too. This is pretty long, sorry 😂

Here's the original post for reference: bsky.app/profile/tender…

Very fair! They don’t! And I think it’s valuable to make that clear to people. However, unlike threads, fibers have clear, deterministic seams of where race conditions could happen. They swap in well defined ways (blocking operations), and never at the instruction level.

I think people with alot of thread experience (or only a little) understate the complexity of threading - and Fibers do lower the cognitive overhead of reasoning about your concurrent code.

Also fair! Hard to say how important this is generally. Several months ago I was working on some jobs which did a ton of calls to BCrypt and I was shocked when I saw all of my CPUs pegged at nearly 100%! I found the PR where you added GVL release which was such a great idea, ty!

That led to an enthusiasm for what GVL release in CPU bound C code could yield. I tried finding more examples of this in the ecosystem and found almost nothing. I posed a question to the OJ gem and the response was that it would not provide any benefit.github.com/ohler55/oj/dis…

So almost nothing does this. And the community sentiment seems to be increasingly "dont write C, instead write Ruby and improve YJIT".
I can’t argue that losing GVL release for expensive operations is unfortunate

But almost nothing does it, and likely we won’t see more code take advantage of it in the future. BCrypt would scale more poorly for a fiber based server - I’m not sure it would actually make a noticeable difference.

I love this point because it highlights a misleading talking point of fibers. "They parallelize IO!". Yes, so have threads since basically forever in Ruby. Even pre-1.9 green threads parallelized IO.

But it isn’t just that they do it that is valuable. It’s _how_ they do it. They abstract the Reactor pattern, which better handles IO. I think this article on Go has a nice perspective on the value of goroutines vs threads and lands on a similar reason shane.ai/posts/threads-…

Overall though - it's murky territory. Because to your later point, at a small scale level - how important is that really?

It seems from the outside that fibers (and ractors imo) are a symptom of a lack of concurrency direction within core Ruby and ideas/approaches coming from various conflicting directions as a result of that. Not saying fibers and ractors are bad, I am very positive towards both!

But writing a blog series/book and RubyConf talk on the entirety of the Ruby concurrency landscape, I feel this very deeply. Explaining it all to people cohesively is _hard_. Probably because it isn’t cohesive.

In the Java world you have one representation of concurrency: the thread. And now they’ve added a way to more easily scale IO using… (virtual) threads. Damn that’s easy to describe 😂 (I'm oversimplifying, but still)

I'd written high throughput IO systems using EventMachine previously - so I had an early interest/enthusiasm for fibers, async and all the work Samuel has done. I’m inclined to be pro fiber, but I also think there is a lot of misinterpretation of the values of fibers out there.

Fibers are effectively node.js, without function colors. Node works this way and scales pretty well it would seem. I’m mixed on that as a final answer.

I think Fibers are great, but they're not a silver bullet. But Fibers vs Threads vs Ractors vs Processes is still, unfortunately, a complicated thing to answer. And I hope we can all improve that with time and compress some of the complexity.

My recommendation comes down to - what’s the simplest, safest way to achieve what you’re looking to do. I think for anything people are expecting to parallelize at their app code level, it’s IO. And I think Async is a more deterministic way to do that with less footguns.

Outside of that you lean on the tools available to you for what they’re good at, which will reasonably be written in whatever concurrency options fit best (Sidekiq, SolidQueue, Paralle gem, Puma, Pitchfork, Falcon, whatever)

It'd be nice to have a simpler concurrency future for Ruby and give people very clear and simple advice about what to choose and when. I want MN to be successful, that’s why I contributed the kqueue implementation to give more people a chance to try it github.com/ruby/ruby/pull…

Maybe at some point with a thread scaling as well as a fiber, there isn't even a need for fibers? But they'll still be there. Or maybe there is a future where Ractors are stable and popular, and the combo ends up Ractors + Fibers as the dominant paradigm.

I like the concept of a Ruby future where it's all Ractors and Fibers, with a cohesive model between them. One can dream 😂