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 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-productivity language for small teams.
For example, NodeJS and Go barely existed when many of those companies were founded (or, in some cases like AirBnB, didn't exist), so I definitely think there is likely to be a different list of languages for top startups in 10 years time.
I do think, though, that it is definitely no accident that languages like Java and C++ appear way under-represented given their prevalence in the industry at large. My personal theory is that what is most important for developer productivity is the feedback loop between making a code change and being able to see that change in a running application. Scripting languages make it often as trivial as saving a file and refreshing, while compiled languages can, in addition to having a costly compile step, also have a very costly deployment step. I remember in the early 00s the painful experience of editing Java code and waiting nearly minutes for a local deploy step to get that code running again.
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.)
I feel like this data should be one of the most important aspect of choosing a tech stack. Even though it’s hard to infer the data because there’s years of delay between inital tech stack choice and the success of the startup.
Though we hired a bunch of people from Google, who brought Java, and we went hard towards SOA. Around 2013 there was a Java vs Ruby war in engineering, with many upset people. It ended in peaceful coexistence. But most things in the main payment flow ended up Java.