Live data from Hacker News

A Deep Dive into Solid Queue for Ruby on Rails

blog.appsignal.com

1–10 of 50 posts

Re: A Deep Dive into Solid Queue for Ruby on Rails

#2
I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs crisscrossing datacenters and tracking any issue became literally impossible. Massively turned me off to both that company and ruby in general.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#3
post #2

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs cri…

Don't let one company's misuse of a language turn you off the entire thing!

Re: A Deep Dive into Solid Queue for Ruby on Rails

#4
post #2

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs cri…

Ruby and the age of “I don’t care what type this variable is, it quacks like a duck!” is over and dead. Improvements to type systems have shown there is a better way to do software development.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#5
post #2

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs cri…

Neither sticking everything into a queue nor going multi-region are Ruby’s fault.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#6
post #2

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs cri…

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

Re: A Deep Dive into Solid Queue for Ruby on Rails

#7
post #6
post #2

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs cri…

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

Culture around a language influences what choices are made.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#8
post #6

Earlier quoted context omitted.

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

Culture around a language influences what choices are made.

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.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#9
post #6

Earlier quoted context omitted.

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

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.

Re: A Deep Dive into Solid Queue for Ruby on Rails

#10

Earlier quoted context omitted.

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.

Doesn't Ruby, like Python, have a GIL? I always found that one is enough to encourage some "premature scalable architecture"
Post reply on HN