Well, I guess the crazy correlation between initial server-side tech choice and valuation has just gotten a lot crazier: https://twitter.com/logicmason/status/1371255029412233218 Edit: Based on the published data I can find, Stripe and Coinbase alone have added more to their valuations in the last year than the total valuation of the top 50 YC-funded startups including Stripe and Coinbase was last year.
I think that correlation can be somewhat misleading, given that there has got be a strong correlation between timing of when those companies launched and their choice of initial programming languages. I mean, nearly all of the top companies in that list were started in the very late '00s and early '10s time frame, when Ruby (and to a lesser extent Rails) was (a) very well established and (b) known for being a high-pr…
FWIW, Airbnb has moved more and more of its backend tech stack off of Rails and onto the JVM; I'm not sure if that's true of other companies in the list. Since that effort started in... 2013-ish? Airbnb went from single-digit billions in valuation to three digit billions, despite a global pandemic ravaging the travel sector. So it's not as clear cut as that list makes it look! Most of Airbnb's valuation was made during a time when it was actively switching away from being a Ruby/Rails shop, and onto a hybrid-but-dominated-by-JVM (backend) company.
I agree generally that productivity helps differentiate successful software companies from unsuccessful ones (although there are lots of other factors too). I think it's more nuanced though than just the feedback between code change in editor to change reflected in locally running application. I used to work on DevTools at Airbnb, and the Rails app was viewed as much less productive to work in according to internal surveys than Java services, despite not needing to wait for Gradle builds. One reason the Java services felt more productive was because the delta between code change and code running in production was much lower — in part because the type system caught more bugs, so there were fewer rollbacks. The Rails monolith needed massive test coverage to keep it stable, and even then, tests missed bugs that Java's type system — as anemic as it is — caught. (Of course, the Java services had tests too; the advantage was they had both types and tests.) Rollbacks caused more havoc than a little time waiting for a Gradle build. FWIW, there were also small Rails services outside of the Ruby monolith, but those tended to not be particularly popular to work on either — so it wasn't just about services vs monolith. Although not everyone felt this way, overall more folks preferred Java to Ruby once Airbnb hit a certain size, even in terms of productivity. People didn't feel done with their change until it shipped successfully, so faster time-to-see-local-changes but slower time-to-ship-overall due to rollbacks ended up feeling less productive overall — especially as code aged and the original authors moved onto different projects or left the company.
Of course, that's something that matters more once you have a larger team and a larger (and older) codebase. Since the list is about original tech stack rather than current tech stack, maybe in ten years the list will still look biased towards environments that favor fast local changes over anything else — even though that won't necessarily reflect what those companies still use.
(Or maybe newer languages like Go and TypeScript balance time-to-see-local-changes and low-defect-rate well enough that the difference will be less obvious? Go's incredibly fast build times feel almost like a scripting language, and a TypeScript/React setup with Hot Module Reloading makes Rails feel practically sluggish in comparison; maybe this is no longer as much of a tradeoff.)