I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be better off using a typed language with true multithreading and a solid GC.
> Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails.
https://spreecommerce.org/ruby-on-rails-most-popular-among-t...
I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
You, on the other hand, are moving the goalposts.
Not to mention that a lot of the hardware costs are language-agnostic: database servers, disk volume.
You can easily reach "scale" (earn millions of dollars, serve millions of customers) while still running on 2-4 web servers.
But I've done it with Python and I can't see why Ruby would be any different.
Why is that so surprising? Nobody sane does anything CPU-intensive in their webapps.
Of course if we had a few billion users , diff story, but approximately no one does.
Looking from the outside, all I can say is that both Github and especially Stripe have continued to churn out features and entire product lines well after they reached global scale…
Regarding their economics, I’d have to see a serious study proving that that the effect in infra and server costs is not only real but also non-negligible, ie, it has a real impact on the bottom line, shareholder value, company efficiency, competitiveness, or what-have-you…
The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go.
It's just a matter of this logic being scaled to big levels
Engineers love to pull out the "it doesn't scale" card with alternative language suggestions that usually align with whatever pet/fad language they've been playing with because its new and shiny (I accuse myself here as well). At some point a business is successful enough, like Stripe, where the risk of changing out an entire tech stack outweighs any perceived benefit.
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
We should all be so lucky
This does seem to at least rhyme with twitter's experience, and maybe also github, at least as observed from outside, where a pretty innovative initial product has difficulty progressing after a period of massive scaling.
But also: Is the lesson maybe just knowing when to pivot to more efficient runtime environments? For instance, I believe facebook had a similar experience with php, and pivoted to running it on a custom vm. Did stripe wait too long to do that kind of pivot? Or perhaps you were just there in the middle of it, which is bound to be a messy time.
For my part, my intuition is that my last project, in java, seemed to be more productive than the current project in go, and another current project, in python, also seems to be working better. But there are so many variables, it's impossible to untangle causality.