Hacker News new | ask | show | jobs
by likeabbas 1200 days ago
Once you reach scale, Ruby can be a limiting factor depending on how much latency impacts your revenue. And it's not so easy to remove that dependency as I've seen.
3 comments

Rails can easily serve up pages in <100ms. If you do have an endpoint that is CPU-bound to where you can’t meet your SLA goals, you can serve up just that endpoint in Rust or Golang. But that’s rare.

Usually what happens at scale is that the SQL database starts slowing down as more data is loaded in. Partitioning, indexes and painful refactorings aren’t prioritized. Engineering will champion “a faster language”—that incidentally allows them a new data model where they add in proper indexes at the start. They aren’t really incentivized to realize they could see the same gains by just improving their existing data inside the Rails monolith.

Source: experience improving performance (including latency) with multi-billion-dollar Rails monoliths

You can’t scale Ruby to <25ms which is important for some businesses where every 10ms is millions in lost processing
There’s vanishingly few businesses that need <25ms. What business did you have in mind? Outside of trading , which yea of course that’s the wrong choice.
Low latency credit card processing.
> Once you reach scale

We should all be so lucky

Latency is important to sales and it hasn't been an issue for Shopify. In my experience, you need people that understand how to scale things more than you need a scalable language.