Hacker News new | ask | show | jobs
by trevorhinesley 357 days ago
I’ve never felt like “throw everything into a queue” was a mindset within the Ruby community, nor have we done that at my companies. And multi-region is a business decision.
2 comments

Resque was a staple for a long long time. In the jvm world, throw everything into Kafka is also a staple of a lot of "enterprise" shops. Or SQS for AWS places I've worked at. I think it is not a ruby language thing, but a certain kind of architecture thing.
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.
Rails 8 came out in November, and `rails new` generates an app with the solid trio in the Gemfile. Been fun playing around with it for new side projects :)
Doesn't Ruby, like Python, have a GIL? I always found that one is enough to encourage some "premature scalable architecture"
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.