6 ms·

I wish the author dove deeper into "does ruby scale" with hard numbers instead of pointing at big companies. If Shopify, Github, or Gitlab wrote their code in

by itake 3y ago

I wish the author dove deeper into "does ruby scale" with hard numbers instead of pointing at big companies. If Shopify, Github, or Gitlab wrote their code in golang or rust, would they need less CPU and memory? Would they have less bugs? Are refactors fast? How has RoR's ever changing JS ecosystem impacted these organizations?

AlchemistCamp 3y ago
If they’d written their code in golang or rust, they’d have been out-competed by a competitor who iterated faster and got better product-market fit. The only reason the three companies have the opportunity to suffer from scaling challenges is that they were wildly successful.
- pantulis 3y ago
  Or, putting it the other way around: they out-competed their competitors because they were using RoR.
  - itake 3y ago
    Do you have a source? which is bigger: WooCommerce or Shopify? Does WooCommerce use Ruby or PHP?
    - mathverse 3y ago
      Your comparison does not really make sense to me or I am perhaps missing your point. PHP and Ruby are in the same category of fast response loop and ability to develop quickly.
- itake 3y ago
  - Uber is built on Golang. - Lyft is built in Python (which IMHO, is comparable to ruby). Who out computed who? - WooCommerce is written in PHP. - Shopify is written in Ruby. Who has more customers? hint: [0] I do not think programming languages define a company's success. [0] - https://6sense.com/tech/ecommerce-platform/woocommerce-vs-shopify https://6sense.com/tech/ecommerce-platform/woocommerce-vs-sh...
  - les_diabolique 3y ago
    Uber was initially built in Python, then migrated to Node and now Go
  - lawgimenez 3y ago
    Instagram is still on Django.
- pixelatedgengar 3y ago
  [dead]
- report-to-trees 3y ago
  Having worked for one of those company's, I think the productivity of Rails is overstated. Yes it's quick to get a rough demo and POC working (which is already plenty quick in many other frameworks) but once you get into the weeds of actually building and iterating the difference is not so great. I think particularly if you look at these established companies, what tech stack they are running often is just a matter of what the founders knew at the time. The business wasn't successful because they chose Rails, it was a successful business who happened to pick Rails to start with.
  - AlchemistCamp 3y ago
    Were you working for them in the early days as one of the first 10 employees or were you there after they’d already found product-market fit?
  - alberth 3y ago
    What framework would you recommend instead? Just curious.
    - randomdata 3y ago
      The one you already know is going to be the best framework for quickly iterating on an early business idea.
- MrRolleyes 3y ago
  I don't even think that's it—as convenient it is to explain—if someone knew exactly what product they were building java would have done just fine. Realistically scaling just isn't a bottleneck for most companies at the beginning. Excepting maybe, maybe, twitter.
mooktakim 3y ago
Looking at big companies is a good indicator of whether "it can scale". If you want to know what scales better, thats when benchmark would be useful.
- danmaz74 3y ago
  Looking at big companies is a bad metric if you're not a big company - or at least a rich one. Startups and in general smaller companies need to be very efficient with their developers, because they can't get many. Big companies have other issues, eg coordinating the work of thousands of developers, and choose their tooling accordingly.
  - mooktakim 3y ago
    Not that bad metric if you consider they had to start from something. The argument on "rails dont scale" is that eventually you need to rewrite it. Which isn't actually true as there are many companies that continue to use it even though they've scaled, in product usage and employees.
manojlds 3y ago
If Shopify, GitHub or Gitlab didn't start in RoR, would they have survived such that scale became a factor?
- pmontra 3y ago
  We will never know. What we know is that it didn't harm them. Add Twitter to the list. They started with Rails, then switched to something else. Too many background jobs, Ruby is not ideal for that. However they became Twitter and owned that space before having to switch so Rails didn't harm them too.
rodrigodlu 3y ago
I worked in one product that a "simple" re-architecture from rails 3 to rails 5+(async-as-most-as-we-can) was more than enough to handle MAU into millions and simultaneous sessions in high thousands. Enough for a big exit for the founders indeed and having an edge against other players using golang, but with double the headcount than my case. We also got 98~100 lighthouse by using pure JS with sprinkles of stimulus after the initial rendering.
- JustLurking2022 3y ago
  Thousands of simultaneous sessions isn't all that many, if you are scaling your infra to dozens of servers. Can be handled by a single server, if code is optimized.
  - rodrigodlu 3y ago
    4x16gb/2x offpeak pure ec2 deployed with codedeploy that was easily paid and profitable 2x8gb elasticsearch 1x512mb redis 1xRDS mysql 16gb low thousands/year of cloudflare enterprise half of the budget (personnel+infra) than the next competitor in the niche I worked
BiteCode_dev 3y ago
Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language. It's not a ruby thing, it's just that servers are beast nowadays, and cheap. And devs are more expensive than ever.
- andrewstuart 3y ago
  You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.
  - vidarh 3y ago
    Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
e12e 3y ago
> How has RoR's ever changing JS ecosystem impacted these organizations? As much as I think RoRs initial love for coffee script was a mistake (although it certainly did help at a time when javascript was in a horrible, braindead place) - I'm not sure I'd like the js mess at Rails' feet. I think that the team navigated js integration as well as could be expected - and everyone was happy in version 7 when js support in browsers had advanced to the point that most of the special handling could simply be ripped out. The remaining issue IMNHO is that there's no browser support for typescript - and using ts dictates a build pipeline which would otherwise be needless complexity with modern js and js modules.
- arrowsmith 3y ago
  > javascript was in a horrible, braindead place was?
  - e12e 3y ago
    Before modules, "let"/"const", uniform APIs cross browsers (xmlhttprequest, anyone?) - js was much, much worse. Rails dates back to before 2005 - before chrome existed, and around the time Firefox emerged from Netscape.
- PH95VuimJjqBqy 3y ago
  coffeescript was an obvious deadend at the time it was created. The only thing that could have saved (maybe) is better tooling but the community had no interest in it (who knows why). Rust feels like this too.
  - e12e 3y ago
    If I remember correctly, the first version of coffee script was quite sane, but the second version was completely different, and IMNHO much worse? I think the initial version was a moderate enhancement on js, fixing some things like global scope etc?
herbst 3y ago
I was serving a big database of information to up to 1000 concurrent users on a 10$ cloud server without bigger issues. I don't think many projects get to a 1000 concurrent connections point ever. IMO when you work with it properly it's so little of an issue (especially compared to the Dev time saved) that most Rails Devs simply don't care about the 'ruby doesn't scale' talk

by itake 3y ago

AlchemistCamp 3y ago

If they’d written their code in golang or rust, they’d have been out-competed by a competitor who iterated faster and got better product-market fit. The only reason the three companies have the opportunity to suffer from scaling challenges is that they were wildly successful.

pantulis 3y ago
Or, putting it the other way around: they out-competed their competitors because they were using RoR.
- itake 3y ago
  Do you have a source? which is bigger: WooCommerce or Shopify? Does WooCommerce use Ruby or PHP?
  - mathverse 3y ago
    Your comparison does not really make sense to me or I am perhaps missing your point. PHP and Ruby are in the same category of fast response loop and ability to develop quickly.
itake 3y ago
- Uber is built on Golang. - Lyft is built in Python (which IMHO, is comparable to ruby). Who out computed who? - WooCommerce is written in PHP. - Shopify is written in Ruby. Who has more customers? hint: [0] I do not think programming languages define a company's success. [0] - https://6sense.com/tech/ecommerce-platform/woocommerce-vs-shopify https://6sense.com/tech/ecommerce-platform/woocommerce-vs-sh...
- les_diabolique 3y ago
  Uber was initially built in Python, then migrated to Node and now Go
- lawgimenez 3y ago
  Instagram is still on Django.
pixelatedgengar 3y ago
[dead]
report-to-trees 3y ago
Having worked for one of those company's, I think the productivity of Rails is overstated. Yes it's quick to get a rough demo and POC working (which is already plenty quick in many other frameworks) but once you get into the weeds of actually building and iterating the difference is not so great. I think particularly if you look at these established companies, what tech stack they are running often is just a matter of what the founders knew at the time. The business wasn't successful because they chose Rails, it was a successful business who happened to pick Rails to start with.
- AlchemistCamp 3y ago
  Were you working for them in the early days as one of the first 10 employees or were you there after they’d already found product-market fit?
- alberth 3y ago
  What framework would you recommend instead? Just curious.
  - randomdata 3y ago
    The one you already know is going to be the best framework for quickly iterating on an early business idea.
MrRolleyes 3y ago
I don't even think that's it—as convenient it is to explain—if someone knew exactly what product they were building java would have done just fine. Realistically scaling just isn't a bottleneck for most companies at the beginning. Excepting maybe, maybe, twitter.

mooktakim 3y ago

Looking at big companies is a good indicator of whether "it can scale". If you want to know what scales better, thats when benchmark would be useful.

danmaz74 3y ago
Looking at big companies is a bad metric if you're not a big company - or at least a rich one. Startups and in general smaller companies need to be very efficient with their developers, because they can't get many. Big companies have other issues, eg coordinating the work of thousands of developers, and choose their tooling accordingly.
- mooktakim 3y ago
  Not that bad metric if you consider they had to start from something. The argument on "rails dont scale" is that eventually you need to rewrite it. Which isn't actually true as there are many companies that continue to use it even though they've scaled, in product usage and employees.

manojlds 3y ago

If Shopify, GitHub or Gitlab didn't start in RoR, would they have survived such that scale became a factor?

pmontra 3y ago
We will never know. What we know is that it didn't harm them. Add Twitter to the list. They started with Rails, then switched to something else. Too many background jobs, Ruby is not ideal for that. However they became Twitter and owned that space before having to switch so Rails didn't harm them too.

rodrigodlu 3y ago

I worked in one product that a "simple" re-architecture from rails 3 to rails 5+(async-as-most-as-we-can) was more than enough to handle MAU into millions and simultaneous sessions in high thousands. Enough for a big exit for the founders indeed and having an edge against other players using golang, but with double the headcount than my case. We also got 98~100 lighthouse by using pure JS with sprinkles of stimulus after the initial rendering.

JustLurking2022 3y ago
Thousands of simultaneous sessions isn't all that many, if you are scaling your infra to dozens of servers. Can be handled by a single server, if code is optimized.
- rodrigodlu 3y ago
  4x16gb/2x offpeak pure ec2 deployed with codedeploy that was easily paid and profitable 2x8gb elasticsearch 1x512mb redis 1xRDS mysql 16gb low thousands/year of cloudflare enterprise half of the budget (personnel+infra) than the next competitor in the niche I worked

BiteCode_dev 3y ago

Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language. It's not a ruby thing, it's just that servers are beast nowadays, and cheap. And devs are more expensive than ever.

andrewstuart 3y ago
You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.
- vidarh 3y ago
  Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.

e12e 3y ago

> How has RoR's ever changing JS ecosystem impacted these organizations? As much as I think RoRs initial love for coffee script was a mistake (although it certainly did help at a time when javascript was in a horrible, braindead place) - I'm not sure I'd like the js mess at Rails' feet. I think that the team navigated js integration as well as could be expected - and everyone was happy in version 7 when js support in browsers had advanced to the point that most of the special handling could simply be ripped out. The remaining issue IMNHO is that there's no browser support for typescript - and using ts dictates a build pipeline which would otherwise be needless complexity with modern js and js modules.

arrowsmith 3y ago
> javascript was in a horrible, braindead place was?
- e12e 3y ago
  Before modules, "let"/"const", uniform APIs cross browsers (xmlhttprequest, anyone?) - js was much, much worse. Rails dates back to before 2005 - before chrome existed, and around the time Firefox emerged from Netscape.
PH95VuimJjqBqy 3y ago
coffeescript was an obvious deadend at the time it was created. The only thing that could have saved (maybe) is better tooling but the community had no interest in it (who knows why). Rust feels like this too.
- e12e 3y ago
  If I remember correctly, the first version of coffee script was quite sane, but the second version was completely different, and IMNHO much worse? I think the initial version was a moderate enhancement on js, fixing some things like global scope etc?

herbst 3y ago

I was serving a big database of information to up to 1000 concurrent users on a 10$ cloud server without bigger issues. I don't think many projects get to a 1000 concurrent connections point ever. IMO when you work with it properly it's so little of an issue (especially compared to the Dev time saved) that most Rails Devs simply don't care about the 'ruby doesn't scale' talk