I think this is because, in the 2000s, when a lot of these companies were founded, Ruby and Python hit an pretty much empty sweetspot for web application development in between quickly thrown together scripts and the super heavy enterprisey frameworks.

But since then, that space has gotten a lot more crowded from all sides. There is now a pretty big selection of mature technology to pick from depending on your needs.

In the case of Python, it got also a massive boost from its popularity in datascience. Couple of years ago I thought Python web development is dying out slowly, but seems to have swung back quite a bit.

I think most frameworks/languages swing in and out of the lime light. Using Ruby as an example, it was great then got really hot, then as you said Python got the data science boost and moved a lot of people there. I'm curious if Matz makes good on his promise to 3x Ruby that will result in Ruby getting some more data science libraries.

That said, last I checked regarding performance Rails and Django were pretty much neck and neck with a negligible difference with rails being very slightly faster (iirc).

I think also a big reason why Ruby is feature so heavily in this list is because of it's focus of developer productivity. It's a nice mesh of flexibility and convention. Generally all projects are setup and organized the same but you can still write a conditional if statement a dozen ways. Compared to my personal experience working with Django and Python are the woes of getting everything configured and setup for each project which is frankly a pita. Also, Python is fairly regimented on a lot of flexibility which has its perks too.

I'd caution people outside hyper-growth startups from drawing that much from this chart. People in that ecosystem have very different utility functions than most software engineers.

Comparatively, I'm sure a chart with database swapped out for language would show a huge over-representation of NoSQL products like Mongo and Couchbase. Yet for the overwhelming majority of projects the right answer is just use a solid SQL product like Postgres.

Again, for SV hyper-growth startups the calculus is different. Mongo has tons of downsides and pitfalls. But the one thing it has going for it is, you can get started fast without having to think about it. Just throw shit in a giant nested key-val map and pull it out later. You don't have to design schemas or provision ahead of time. Change the JSON on the fly, and if you hit performance issues, just throw more hardware at it. Move fast and break things.

For 99% of projects that kind of attitude comes back to bite you in the ass. For every hour that you save today, you'll end up spending ten hours in a year or so from now when you're eventually forced to detangle a crusty sloppy mess.

But for a unicorn-aspiring SV startup, that tradeoff works. Almost any startup would gladly spend a hundred man-hours in a year or two, to get back one man hour today. And that works, because the growth rates are astronomical. In a few years, you'll hopefully be a billion-dollar unicorn with tons of resources to throw at the minefield of quick and dirty technical decisions you made at the seed stage. (More realistically, you simply won't be around anymore, at which point the pitfalls in waiting also don't matter.)

The point is don't necessarily pay too much attention to the decisions made by YC startups. This is true even for regular startups with more prosaic aspirations. (Some of us are more than happy to own $10 million companies, and aren't aiming for billionaire or bust.) If your business model is rooted in 1000% hyper-growth rates, that encourages many tradeoffs that are otherwise deeply pathological.

I couldn’t imagine doing anything in MongoDB or understand why that is desirable.

We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.

You need _more_ guarantees, not fewer.

Have you evaluated MongoDB to see why it's desirable?

Ignorance of a technology is a poor excuse to crap on it. I've used many different technologies over my 15 year career. SQL Server, MySQL, Postgres, MongoDB, Firebase, etc. Each worked well enough, each had it's drawbacks. I'm not here to tell you MongoDB is a silver bullet for every specific use case, but from personal experience I haven't run into an instance where it was a hindrance.

Disclaimer: I currently work for MongoDB.

My big issue with MongoDB is similar to this Potts quote

“I have no problem with god - it's his fan club that scares me.”

MongoDB works fine in niche situations of trying to store large blobs of JSON with extremely different elements. But for the vast majority of cases, data is highly relational. So Mongo is just a crutch that companies like because of the lower skill ceiling. Most of these startups can't be bothered to pay high enough to recruit people who payed attention during their databases lecture. In the long run, it just creates a jumbled mess of db code.

Every project I've worked in, got rid of mongo once they grew to any reasonable size due to cost and maintenance overhead. It's not a hindrance for small projects, but becomes a pain at scale in my experience. Based on that I'd never use it again for anything I plan to scale, gutting it out later is a pain. Might as well build it right the first time.

Not saying you should use it but to reaffirm GP points, the most valued company in that list, Stripe, started with MongoDB: https://www.mongodb.com/blog/post/mongodb-powering-the-magic...

And this is a financial company.

The common misconception is that MongoDB stores JSON blobs. The JSON you see is converted seamlessly to BSON and is type encoded. This allows use to apply indexes at any level in the object and use complex query expressions at any level in the object.

I use Python by choice and the more there is growing need for Natural Language Processing, Machine Learning, Data Mining, the more I can not leave Python.

I try Rust, Ruby and others on the side. But Python is just so heavily fortified now that I constantly suggest startups who are going to build non-trivial tech to select Python. Also the whole Linux, deployment, etc. space is filled with Python.

Biology, Physics, Math folks also use more Python than any other language.

.NET Core can deploy to Linux now.

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy...

It's also faster than Node. Significantly faster. I was troubleshooting a connection issue to a db from a .NET Core API so I set up a NodeJS API hitting the same db to isolate it to the connection. After I was done fixing things, I compared the API response speeds for the same thing. .NET Core outperformed Node dramatically just like in benchmarks.

I've been running a website and API with .NET Core for over a year...deploying to Digital Ocean droplets that run Ubuntu. Using MySQL instead of PostGres, sorry HN. It all runs like a champ, and costs me $17.05 USD per month. I only have about 100 users, so I'll scale if/when needed. I built it all on a refurb $700 macbook air I bought in 2016.

...and I can concur on the performance. It's hilariously fast.

Hmm. If you believe in microservices then I think it's fine to use python for your ML pipelines and API's, and some other language for the rest of your application software.

what about R?

or Scala if you need bigger scale?

In my corner of the world, most professors in those disciplines do obscene things with Mathematica as their first choice rather than using a more traditional programming language.

After that there's a fairly healthy dose of C and Fortran from the performance-oriented crowd, quite a few people use Python (but its hard to express just how completely and totally alien their uses are from one another), and the closer you shift to biology or stats the more likely you are to see somebody using R. A few enthusiasts are extremely excited about Julia.

Yes let me just spin up my R web server.

Your web server isn't written in Python either, though.

I recall the bootcamp craze that happened a few years ago and most of them were Ruby (with Rails) based.

The result of that is that if I lookup basic concepts in web dev today I'll still find a lot of tutorials and courses aimed at total beginners for Ruby. Meaning that even today, Ruby would be a good choice for CS students in a program where they have no web dev course if they wanted to get a small website running.

Now Python is gaining adoption as an introductory language (MIT ditched Scheme for it!). My bet is that a lot of times python was chosen simply because everyone in the team knew it.

If I knew the scope of the project right when running git init I wouldn't pick these two, but my gut feeling is that a lot of these started as "let's get a demo working, we won't have more than 10 users ever anyways unless we get funding!"

I started learning Python some 7 months after starting to learn C (my first language). I didn't really grok logical program structure until the burden of mem management was behind me.

So, relieving that burden allowed me a playground to pseudocode a program and then translate that logic to a more optimized inplementation.

I still use that strategy in forming mental models.

But now it's a matter of placing weak joints on a pipeline and accepting bottlenecks where they arise.

Can I MVP in 2-6 weeks on those 10 (the startup) alpha users? Fine. Can I leverage my engineering strengths and understand replacement priorities? That's my goal and I run very far from startups that want to build panickedly with toothpicks and glue.

After building two companies with Python, and then one with Javascript, I can see a huge difference. With Python, you get a predictable development velocity. With Javascript, there's lots of unpredictability (this is rapidly improving) because of thrash in the ecosystem. It's hard to overstate the value of predictable timelines and predictable development velocity when building a business.

Curious where in javascript you saw a lot of unpredictability?

Maintaining JS is a treadmill on fast: takes a lot of work to stand in place, which is horrible if you are trying to get anywhere.

We have been ripping out node bc basic backend frameworks are too small and mercurial, so breaking API changes every year on simple things like making an HTTP request has meant a lot of time not spent on our users. The ROI is often ultimately miniscule perf, and ironically, CVE fixes from such a cowboy culture. (We are also ripping out node bc current inability to work with data ecosystem well + shitshow that is build times / maintaining them.)

Frontend has been getting better. Part of that is we have largely stopped adding any dependencies and been chiseling down to react + a few components, and between them + the webpack team, focusing on the few teams we trust to respect end user code more than they value whatever feature idea that month.

I spent years on making JS better and we have built stuff to make it sing, so bittersweet business decision driven more by the unmaintainable code culture than the language (npm/node are growing up, V8 is amazing, React achieved a lot of what early framework people marched for, ... ).

EDIT 1: Part of the technical problem may be around npm <> semvar and in turn, the dev culture around it. Dutifully updating semvars upon breaking changes may have given a false sense of being friendly for maintenance. Major upgrades are still necessary in practice due to peer dependency requirements triggered by CVEs etc. It's ~awesome to now see breaking changes in better modules. However, having to do via searching github stinks, and horrifying how many there are. This is still a far cry from not consistently breaking everywhere, gofmt, etc.

EDIT 2: I don't blame OSS devs for hobby projects unrelated to their work and with no claims of aiming for prod ready / corp use. But as soon as we get to core node infra teams and their VC sponsors causing a bait-and-switch on infra focus, or tech leads at unicorns & bigco's doing their here today / gone tomorrow thing, etc., I get heart pain around adding any dependencies around this broken tech<>social ecosystem.

In the JS world, this is why Ember is so awesome. People criticize it for including everything and the kitchen sink, but most frontend apps that go anywhere actually need all that. And Ember guarantees that it all works together, with a clear upgrade path.

An example of this from my experience: I was working on a side project and ended up doing 2 major version upgrades on a core JS library (maybe routing?) before I even completed the MVP. Definitely not what I wanted to spend my time on at that point.

I believe Deno links to dependencies directly so that you can still rely on old(er) versions, but not sure it would have helped in this case.

I use python because its just so much easier to develop. I think for startups iteration speed is magnitudes more important than running efficiency of code

Node will probably start showing up more, though I'd say its biggest weakness is that there's no full framework (that takes care of everything) that's truly dominant. Working in node, feels like working in Java, especially if you're using Typescript. Unlike Ruby and Python, Javascript / TS suffers from the paradox of choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice

Javascript's ecosystem isn't just fragmented, it is downright capricious. In all my decades in tech, I've never seen an environment where dependencies rot out of maintainability faster.

+1 for choosing .NET Core. I'm right there with you. Extra points for F#.

Ruby on Rails in particular made it really easy to get up and going in a few hours or days. I think Python with Django and Flask has occupied that spot.

And for ML and AI-focussed startups, Python is a no-brainer.