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.

- 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-sh...

Uber was initially built in Python, then migrated to Node and now Go

Instagram is still on Django.

Or, putting it the other way around: they out-competed their competitors because they were using RoR.

Do you have a source? which is bigger: WooCommerce or Shopify? Does WooCommerce use Ruby or PHP?

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.

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.

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?

What framework would you recommend instead?

Just curious.

The one you already know is going to be the best framework for quickly iterating on an early business idea.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

This debate has been going in circle over and over. It's the same arguments than 10 years ago, and the answers are the same.

No it's not saying bad performance doesn't matter.

Yes Go can make application more responsible.

But you have to balance out a lot of compromises in a project, and Pareto tend to favor those languages in the majority of situations because of cost, skills, resources and constraints.

etc.

> 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.

> javascript was in a horrible, braindead place

was?

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.

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.

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?

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