trevorturk

I think the ActionCable PR is here: https://github.com/rails/rails/pull/50979 -- it seems like it's going well, but taking some time. I think that should be interesting for some use cases, but we'll have to see if/how that makes deployment/operations more complex. For example, if you're better off with the bulk of your app running w/ threads on Puma, would you run the ActionCable stuff w/ fibers on Falcon? Or maybe you just have an app that's doing mostly streaming of AI API responses or something?

Anyway, I'd be careful about over-promoting Falcon/Async, even as one of the relatively few people that's running in a large-ish production app. In my case, I'm doing a LOT of hanging waiting on API responses from weather data sources, and I want to transform the JSON and do some data point conversion in real time. So even in my case, I think it's better for me to switch (see https://github.com/socketry/async-examples for me doing some experiments) because I'm often waiting on API responses (in real time) that can take 1-2 seconds (!) but then I'm still doing some heavy CPU work reading and writing JSON blobs. I saw a pretty good speedup with YJIT, so I think I'm not entirely IO bound, if that makes sense.

I think it's great to have more options for those of us that love Ruby, so we don't need to switch to Node.js or something else for this kind of work. But I think it's likely that existing Rails apps (and typical CRUD Rails apps etc) will probably want to stick with a thread-based model. We'll see how it all shakes out over the next couple years, and I think you're right that it's exciting stuff. Between all the work on YJIT etc, and the possibilities for Node.js-type or Go type use-cases being possible/reasonable with Fibers, it's a great time for Ruby!

http://hckrnews.com/ is an awesome way to keep up with hacker news without missing things if you take a few days off.