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.
cortesoft•2h ago
Don't let one company's misuse of a language turn you off the entire thing!
teaearlgraycold•2h ago
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.
ch4s3•45m ago
Maybe, the cycle has happened before and maybe come back around again. Dynamic typing is really nice when most of your data looks like bags of strings. Compilers and tools just don’t add a lot when you’re passing around glorified blobs of stringy json-like stuff. Type gymnastics can eat a lot of time where you could otherwise be shipping something useful.
AstroBen•30m ago
Static typing isn't free. Dynamic typing is perfectly viable to build any sized software - there's living proof, far from dead
So we're only left with personal opinion
trevorhinesley•2h ago
Neither sticking everything into a queue nor going multi-region are Ruby’s fault.
rubyfan•2h ago
Yeah this is not the fault of ruby. Sounds more like bad choices that could be made with any language or framework.
charcircuit•2h ago
Culture around a language influences what choices are made.
rubyfan•1h ago
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.
charcircuit•42m ago
Sure bad choices are made everywhere, but I was essentially claiming that when a community has a hammer, they will see nails.
rubyfan•25m ago
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.
trevorhinesley•1h 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.
morkalork•1h ago
Doesn't Ruby, like Python, have a GIL? I always found that one is enough to encourage some "premature scalable architecture"
trevorhinesley•1h ago
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.
aaronblohowiak•31m ago
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.
WillPostForFood•25m ago
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.
throwaway493943•58m ago
I'm going to be brave (but still use a throwaway) and ask the dumb question - what is wrong with putting things in queues to help with performance problems?
If some endpoint is too slow to return a response to the frontend within a reasonable time, enqueueing it via a worker makes sense to me.
That doesn't cover all performance issues but it handles a lot of them. You should also do things like optimize SQL queries, cache in redis or the db, perhaps run multiple threads within an endpoint, etc. but I don't see anything wrong with specifically having dozens of workers/queues. We have that in my work's Rails app.
Happy to hear how I can do things better if I'm missing something.
teyc•40m ago
Queues have several problems
- if the caller is http it may timeout and retry, leading to more jobs being queued
- the caller may no longer care because it took so long and the work is wasted
- if the caller is called from a queue it can cause cascades
- you can fill a disk up and crash the system
rubyfan•33m ago
You’re not missing anything and are correct in that there are plenty of reasons to use queues and defer work that can be handled asynchronously outside of a request/response. This is not specific to ruby or any language for that matter.
The parent indicated the cross region dynamic required extra routing logic and introduced debugging problems.
zdragnar•11m ago
There's two primary areas that I've seen teams get bitten by this personally:
1) Designers don't understand that things are going to happen async, and the UI ends up wanting to make assumptions that everything is happening in real time. Even if it works with the current design, it's one small change away from being impossible to implement.
This is a general difficulty with working in eventually consistent systems, but if you're putting something in a queue because you're too lazy to optimize (rather than the natural complexity of the workload demanding it) you're going to be hurting yourself unnecessarily.
2) Errors get swallowed really easily. Instead of being properly reported to the team and surfaced to a user in a timely manner, the default setting of some configurations to just keep retrying the job later means if you're not monitoring closely you'll end up with tens of thousands of jobs retrying over and over at various intervals.
nkraft11•2h ago
cortesoft•2h ago
teaearlgraycold•2h ago
ch4s3•45m ago
AstroBen•30m ago
So we're only left with personal opinion
trevorhinesley•2h ago
rubyfan•2h ago
charcircuit•2h ago
rubyfan•1h ago
charcircuit•42m ago
rubyfan•25m ago
trevorhinesley•1h ago
morkalork•1h ago
trevorhinesley•1h ago
Regardless, in my experience, when you run into scenarios that need queueing, multi-threading, etc., you need to know what you’re doing.
aaronblohowiak•31m ago
WillPostForFood•25m ago
throwaway493943•58m ago
If some endpoint is too slow to return a response to the frontend within a reasonable time, enqueueing it via a worker makes sense to me.
That doesn't cover all performance issues but it handles a lot of them. You should also do things like optimize SQL queries, cache in redis or the db, perhaps run multiple threads within an endpoint, etc. but I don't see anything wrong with specifically having dozens of workers/queues. We have that in my work's Rails app.
Happy to hear how I can do things better if I'm missing something.
teyc•40m ago
rubyfan•33m ago
The parent indicated the cross region dynamic required extra routing logic and introduced debugging problems.
zdragnar•11m ago
1) Designers don't understand that things are going to happen async, and the UI ends up wanting to make assumptions that everything is happening in real time. Even if it works with the current design, it's one small change away from being impossible to implement.
This is a general difficulty with working in eventually consistent systems, but if you're putting something in a queue because you're too lazy to optimize (rather than the natural complexity of the workload demanding it) you're going to be hurting yourself unnecessarily.
2) Errors get swallowed really easily. Instead of being properly reported to the team and surfaced to a user in a timely manner, the default setting of some configurations to just keep retrying the job later means if you're not monitoring closely you'll end up with tens of thousands of jobs retrying over and over at various intervals.