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.
You could learn the opposite lesson as well, that if you want to create a successful startup you need a dynamic language that responds to business needs and you can put off worrying about infrastructure costs until later.
Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.
That's not my argument. My argument is that without more data, your original statement that "you'd be better off" is just as subjective. In fact, with data, we see rather the opposite picture:
> 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.
I edited my response from "Without more data, your original statement that "you'd be better off" is just as subjective" to the more fully fleshed out comment you see now while I was looking for a link for my sources.
I'm not moving goal posts. I never said you could not be successful with ruby. All I'm saying is that once you hit scale, you would have an easier time cutting costs in a language that could better utilize less infrastructure and thus lowering your operating costs.
Probably because your original comment doesn't say anything about scale and instead says specifically "you'd be better off," which implies "better off from the start." I'm not saying that's what you said, but that's what it reads as.
Yes, 2-4 web servers. And it's not like they are using most expensive configuration, just 4 vCPU per node. CPU utilization is below 20%, so it could even run on a single node, but that's not good for availability.
Why is that so surprising? Nobody sane does anything CPU-intensive in their webapps.
No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements
I am not GP but the argument that typed language is always better to start with has its own fallacy. What if I don't have experience with a typed language and I need to get to Product Market Fit first where most startups fail ? You need to look at it from a business perspective as well. If I only know say Ruby and I can get something up and running with it, I would use that. I wouldn't worry about Typed Language or whatever.
I'm not saying it's not possible to build a successful start up with the language. My argument is just that the language can become a major expense and limiting factor once you reach scale. Many programmers know multiple languages, and if they have a choice then it may be wise to opt for a language that could help you avoid some of these problems later.
I work at a company that does ruby “at scale” too (10mil b2c users). Yes we need more web instances than we would have in go(or whatever). No, it doesn’t really matter at all - web process compute is a tiny fraction of our AWS bill, and a meaninglessly tiny % of overall op-ex. We’re talking sub sub 1%. It doesn’t matter, really.
Of course if we had a few billion users , diff story, but approximately no one does.
What proof is there that companies built on dynamic typed languages struggle with server costs, payroll, or development velocity, though?
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…
> What proof is there that companies built on dynamic typed languages struggle with server costs
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
Rewriting a huge software base from one language to any other is going to cost a lot more than throwing money at scaling infrastructure. If performance is actually a customer observable pain point, a company would be better off investing in performance tuning their own software as well as investing in people to work on Ruby itself.
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.
Stripe already invested in performance tuning and people to improve Ruby. Ya gotta give people some credit for thinking of the first most obvious thing.
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
There’s vanishingly few businesses that need <25ms. What business did you have in mind? Outside of trading , which yea of course that’s the wrong choice.
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.
This ignores internal efforts to speed-up Ruby and make it concurrency safe. Facebook took this method and did well with it. Hack is typed, and its perf is fast. Shockingly fast.
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.
Go is pretty much a better-in-every-way replacement to that entire cluster of developer-friendly languages like Ruby, Python, Node.js etc. A startup in 2023 would need to have pretty good reasons to not start in Go.
Humorously I was just in a conversation within "a startup in 2023" about how Go is not working all that well. Of course opinions vary, but I thought it was an interesting counterpoint to your comment.
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.
