Re:What I Learned at Stripe
by nahname on Tuesday February 28, 2023 @09:02AM
(#34969367)
Your biggest expense will be people. Rails is ancient at this point, but I regularly see people ship product with it in fractions of the time. You can also re-write parts in rust later, when you need to.
[ Parent
| on HN ]
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.
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.
Re:What I Learned at Stripe
by darkerside on Tuesday February 28, 2023 @09:11AM
(#34969465)
> Once you reach scale
We should all be so lucky
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.