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.

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.

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

You edited your response. How many of those companies are profitable?

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.

You, on the other hand, are moving the goalposts.

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.

For overwhelming majority of startups hardware is a tiny fraction of their operating costs.

Not to mention that a lot of the hardware costs are language-agnostic: database servers, disk volume.

Why do people keep misreading what I'm saying. The argument is specifically for WHEN YOU REACH SCALE

To most people "reaching scale" means either revenue number or number of customers (word "when" implies that).

You can easily reach "scale" (earn millions of dollars, serve millions of customers) while still running on 2-4 web servers.

Name one company that runs 4 servers of ruby and earns millions per year

Given that very few companies in the world make their infrastructure public and I never worked in a Ruby shop, I can't.

But I've done it with Python and I can't see why Ruby would be any different.

A company makes millions of dollars through 4 servers running python?

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.

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.

I guess "successful startup" doesn't equate to "scale" ?

No, it doesn't. A successful startup can have a few large customers and millions of dollars in revenue.

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.

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

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.