2 ms·

> Ruby on Rails is scalable for 99.999% of all startups created with it. You are right of course, but not for your stated reasons. Essentially RoR doesn't scal

> Ruby on Rails is scalable for 99.999% of all startups created with it. You are right of course, but not for your stated reasons. Essentially RoR doesn't scale. RoR scalability is a meme, anything else scales much better. From node to PHP, they all can do much more on much less hardware. To achieve hyperscale with RoR you have to throw absurd hardware with layers upon layers of load balancers in front of it. But I'd argue that it doesn't matter at all for a startup. Like you said most won't ever reach the point where they need such a thing. But they all benefit quite dearly from the excellent developer velocity provided by RoR.

zamalek 3y ago
Right, but I do believe that it is important to choose something that scales competently: > most won't ever reach the point where they need such a thing I considered covering this argument in my gp comment. What if your startup does grow to the scale where it becomes an issue? Do you suspend new user signups until you can do the rewrite? Or do you just let things keep spiraling, like GitHub? Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
- gls2ro 3y ago
  I agree about making an informed choice. I disagree with: > Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite). How can this be true when we know that Shopify, Gitlab, Github and all others are using RoR. Here is a more concrete scale[1]: > We served 75.98 Million requests per minute to our commerce platform at peak. That’s 1.27 Million requests per second! Is that a bit enough limit for you? Here is more: > We achieved 99.999+% uptime while averaging 3 Terabytes per minute of egress traffic across our infrastructure [2] [1] https://twitter.com/shopifyeng/status/1597983926126977024 https://twitter.com/shopifyeng/status/1597983926126977024 [2] https://twitter.com/shopifyeng/status/1597983918900510720 https://twitter.com/shopifyeng/status/1597983918900510720
  - kirso 3y ago
    The assertion that the startup will achieve this scale is the main pitfall here imo, the chance is less than 0.01%. By the time you reach this problem, you'll have an army of developers to take care of this.
bigtunacan 3y ago
I'm sorry, but if your answer is that Node and PHP are inherently more scalable than RoR then you've lost me already. I've worked for three successful startups that started on PHP that couldn't scale the PHP code bases with their customer growth. All three rebuilt on Rails and are still in business and on Rails today. Another startup where I'm very close with the founders they are on Node and they say the system is "a complete dumpster fire". They wish they had built on anything else. The company I'm with now is primarily a giant Rails monolith and we have 100s of thousands of users connected at any given time. Our biggest bottleneck isn't Rails it's Postgres. We are dealing with billions of rows and Postgres isn't really even the problem. The problem is our data model wasn't designed in a way that would allow sharding/partitioning. Even this isn't an intractable problem. We create updated schemas, migrate, backfill. What we don't need to do is leave Rails "because it doesn't scale". Most companies that moved off of Rails because of scalability either don't actually understand scalability or it was 15 years ago and they were on Rails 2 when it was still immature.
- djitz 3y ago
  If you have a PHP application and have found that Ruby allowed you to scale or vice versa, it probably just means the skill level of the dev decision makers improved. There are a lot of gotchas and pot holes one can find themselves stumbling into that you really only have to start caring about once you are actually at the point where scale matters.
  - bigtunacan 3y ago
    This I 100% agree with. The parent post was essentially that Rails doesn't scale and "everything else scales better". Most battle tested languages and frameworks can be adequately scaled if you have the right devs. I think that a lot of the reason we see system rewrites due to scalability is more because startups tend to hire developers that like to "build new things fast" and those aren't necessarily the same as the developers that have already dealt with 1M+ users at petabyte scale. Once you become that successful sometimes the solution is to bring in people that have solved these problems of scalability previously. This sometimes results in rewrites in whole or in part because their experience is on a different stack. In one of the PHP to Rails (for scalability) projects I worked on I was contacted quite early in the process. I am a longtime friend with one of the business owners. The existing developers could not scale the product horizontally and were already on the largest instances available at the time so there was no more ability to scale vertically. They had hired a new technical lead that had extensive experience scaling Rails, but most of the team only knew PHP. My team did both Rails and PHP consulting at the time and we were hired to speed up the rewrite in Rails while the PHP devs were doing a mix of trying to keep things running and learn Rails so they could support after the rewrite. The first thing I did was review the existing PHP codebase. I then advised that they not switch to Rails because I firmly believed that in about 3 months the PHP version could be refactored to allow for adequate horizontal scalability. The full rewrite was expected to take a little over a year. The owner agreed that my assessment was probably right, but he still opted for the rewrite because the new lead was competent at scalability and likely would have quit if they stayed on PHP.
web3-is-a-scam 3y ago
The vast majority of “rails doesn’t scale” complaints come from amateurs that don’t understand sql. They blame rails when they write poor queries, do things like join or aggregate in the application, don’t understand indexing, etc…

zamalek 3y ago

Right, but I do believe that it is important to choose something that scales competently: > most won't ever reach the point where they need such a thing I considered covering this argument in my gp comment. What if your startup does grow to the scale where it becomes an issue? Do you suspend new user signups until you can do the rewrite? Or do you just let things keep spiraling, like GitHub? Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).

gls2ro 3y ago
I agree about making an informed choice. I disagree with: > Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite). How can this be true when we know that Shopify, Gitlab, Github and all others are using RoR. Here is a more concrete scale[1]: > We served 75.98 Million requests per minute to our commerce platform at peak. That’s 1.27 Million requests per second! Is that a bit enough limit for you? Here is more: > We achieved 99.999+% uptime while averaging 3 Terabytes per minute of egress traffic across our infrastructure [2] [1] https://twitter.com/shopifyeng/status/1597983926126977024 https://twitter.com/shopifyeng/status/1597983926126977024 [2] https://twitter.com/shopifyeng/status/1597983918900510720 https://twitter.com/shopifyeng/status/1597983918900510720
- kirso 3y ago
  The assertion that the startup will achieve this scale is the main pitfall here imo, the chance is less than 0.01%. By the time you reach this problem, you'll have an army of developers to take care of this.

bigtunacan 3y ago

I'm sorry, but if your answer is that Node and PHP are inherently more scalable than RoR then you've lost me already. I've worked for three successful startups that started on PHP that couldn't scale the PHP code bases with their customer growth. All three rebuilt on Rails and are still in business and on Rails today. Another startup where I'm very close with the founders they are on Node and they say the system is "a complete dumpster fire". They wish they had built on anything else. The company I'm with now is primarily a giant Rails monolith and we have 100s of thousands of users connected at any given time. Our biggest bottleneck isn't Rails it's Postgres. We are dealing with billions of rows and Postgres isn't really even the problem. The problem is our data model wasn't designed in a way that would allow sharding/partitioning. Even this isn't an intractable problem. We create updated schemas, migrate, backfill. What we don't need to do is leave Rails "because it doesn't scale". Most companies that moved off of Rails because of scalability either don't actually understand scalability or it was 15 years ago and they were on Rails 2 when it was still immature.

djitz 3y ago
If you have a PHP application and have found that Ruby allowed you to scale or vice versa, it probably just means the skill level of the dev decision makers improved. There are a lot of gotchas and pot holes one can find themselves stumbling into that you really only have to start caring about once you are actually at the point where scale matters.
- bigtunacan 3y ago
  This I 100% agree with. The parent post was essentially that Rails doesn't scale and "everything else scales better". Most battle tested languages and frameworks can be adequately scaled if you have the right devs. I think that a lot of the reason we see system rewrites due to scalability is more because startups tend to hire developers that like to "build new things fast" and those aren't necessarily the same as the developers that have already dealt with 1M+ users at petabyte scale. Once you become that successful sometimes the solution is to bring in people that have solved these problems of scalability previously. This sometimes results in rewrites in whole or in part because their experience is on a different stack. In one of the PHP to Rails (for scalability) projects I worked on I was contacted quite early in the process. I am a longtime friend with one of the business owners. The existing developers could not scale the product horizontally and were already on the largest instances available at the time so there was no more ability to scale vertically. They had hired a new technical lead that had extensive experience scaling Rails, but most of the team only knew PHP. My team did both Rails and PHP consulting at the time and we were hired to speed up the rewrite in Rails while the PHP devs were doing a mix of trying to keep things running and learn Rails so they could support after the rewrite. The first thing I did was review the existing PHP codebase. I then advised that they not switch to Rails because I firmly believed that in about 3 months the PHP version could be refactored to allow for adequate horizontal scalability. The full rewrite was expected to take a little over a year. The owner agreed that my assessment was probably right, but he still opted for the rewrite because the new lead was competent at scalability and likely would have quit if they stayed on PHP.

web3-is-a-scam 3y ago

The vast majority of “rails doesn’t scale” complaints come from amateurs that don’t understand sql. They blame rails when they write poor queries, do things like join or aggregate in the application, don’t understand indexing, etc…