Yes. But just for the Action Cable parts, as in you'd deploy Action Cable standalone with falcon, and then keep Puma or whatever for the purely transactional requests.

If you don't, you'll notice that your Action Cable latency will be all over the place when a transaction request comes in.

It's acceptable for "hobby" use, but if you try to provide a good user experience with reasonable latency, you can't just collocate Action Cable and the rest of Rails in a single process.

I've heard the same for Windows code signing certs - that's it possible to modify the payload and have the signature still apply.

Needs asynchronous libs to adopt it

Ruby’s built in timeout library creates another thread with a sleep call. If something is blocking on a socket in the C code, the timeout doesn’t work.

That seems kinda verbose to use. It's also a bit suspicious that all the examples discard the results; is it hard to get the results back out?

Please, someone, correct me if I've misunderstood.

The big difference appears to be that async Ruby does not merely give you an easy sugar to perform the sync-over-async antipattern you have described. The real innovation is that, as far as the user is concerned, Ruby is magically turning blocking methods into non-blocking ones.

> This gem is almost a decade old

Hm, the first commit to the gem was in 2017. The gem was not "advertised" so that the interfaces can be polished and done right.

Async gem is hugely improved with Ruby 3.0 release (from December 2020) when Ruby language added "fiber scheduler" feature just to integrate better with Async gem.