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.
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.
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
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.
likeabbas|3 years ago
nthj|3 years ago
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
darkerside|3 years ago
We should all be so lucky
nahname|3 years ago
clintonb|3 years ago