True that it is not uncommon to use Sidekiq or Resque , but Rails 8 is going to be the first version to ship with a queuing system (SolidQueue), later this year. So queueing has been an add-on for 20 years. I don't think it is quite a staple.

It does have a GIL. You’re not wrong, but by that same logic, there’s pitfalls when using multi-threading as well, even in languages where it’s native (e.g., Elixir).

Regardless, in my experience, when you run into scenarios that need queueing, multi-threading, etc., you need to know what you’re doing.

That depends on the Ruby implementation.

MRI (CRuby) has a GVL which is why you might use a forking web server like Puma or Pitchfork.

JRuby and TruffleRuby though have true multi-threading and no GVL.

I’ve used the Concurrent Ruby library with JRuby and Tomcat quite a bit and find works very well for what I need.

Queues are not a ruby specific thing, nor are they particularly pervasive within Rails apps. Having a good framework to handle them doesn’t make it the only tool in the tool belt. On the contrary, the fact that Rails has good tools to fit many different types of system architecture needs is a counterpoint of your assertion.