Hacker News Reader

Comment by rubyfan | Hacker News Reader

Yeah this is not the fault of ruby. Sounds more like bad choices that could be made with any language or framework.

You're totally correct. It's not a problem of ruby per se, but engineers would basically just throw their hands up and say "ruby can't handle this" and sidekiq became the One True Way™. What ensued was the most byzantine software architecture I've ever seen.

Culture around a language influences what choices are made.

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.

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.

Don’t be silly. Bad choices are made in all sorts of languages and teams - this has nothing to do with language. High pressure situations can lead teams to make choices they don’t always foresee as bad until after they are paying the consequences.

Sure bad choices are made everywhere, but I was essentially claiming that when a community has a hammer, they will see nails.

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.

Sort of. In this case the lack of multithreading led engineers to using sidekiq as a stand in.

Funny part: I initially thought you were referring to the word “Byzantine” itself, which tends to carry a negative connotation in English, mostly due to historical bias. But you’re actually talking about Ruby!

If we were to take Byzantine in a more accurate, historical sense, something truly “Byzantine” should be evolving, enduring, top-tier, and built to last for 1k years.

Reply on news.ycombinator.com