My career specialty is deployment at the 10^5 scale and I'd argue that Python has no business on Production systems. Heck, I'm a former career Rubyist and I'd say the same there too. At a certain point statically linked binaries are going to make several classes of hard problems to solve disappear entirely and is IMO baseline criteria for operating at this level.

BEAM at least has some compelling features working in its favor that make it worth exploring operationally, but also it doesn't really operate at that very large scale. It's well-adapted for smaller scale systems.

> It's well-adapted for smaller scale systems.

I wonder what they switch to at WhatsApp when they become medium scale.

Hey. I write Elixir & Erlang sometimes too. I'm an Erlang Ecosystem Foundation member.

There are very real and well-known scalability limits of Erlang clusters and applications that run in them. This isn't someone talking shit, but instead just operating within the limitations imposed by reality. Message passing has overhead -- it's not free.

WhatsApp probably doesn't need nearly as much hardware as you think.

> I'd argue that Python has no business on Production systems

Well yes you would argue, you did. That doesn't make your argument true or important.

Sorry, but at this scale of systems and how often you're replacing hosts, it's absolutely critical that you always have a deployable. That's not provably true in the Python ecosystem (unless you're insane and vendoring all of your dependencies separately for every single application you deploy).

At the end of the day what you need is a statically linked binary. There are tools like cx_freeze and Nuitka that try and get you there but ultimately aren't worth the effort and give you other problems to solve as well. Or you could use cython, but again, more problems. You're simply better off using a language that reduces your (business) risks from the onset.

I'm sorry that that makes you feel bad, but that's facts and anyone working at this scale will tell you so. We pretty much only deal with Python where we have to (in the ML space). If a company is really stubborn about it though it's often better to just not take those jobs.

I think it really does depend on the domain. When it comes to web, "move fast and break things" is the norm, and the expectation. This is exactly where dynamic languages are great - so what if you don't have the cleanest code, so what if you throw exceptions due to mismatched data types, if you can get the MVP out there then you're already half way there. Let future generations deal with the tech debt, using the warchest you amass from all the funding you can get by showing off your successful launch.

For lower level / systems programming, though, I think that's somewhat less true. Think about database plugins like timescale, or VPN solutions, etc - stuff that, if it breaks, somebody's having a really bad day. It's probably worth spending more time on robustness and then a statically typed compiled language can really help eliminate many classes of errors off the bat.

> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses

The classic rebuttal to this is that the company needs the best chance of surviving today, and can fix it tomorrow.

There are problems with this approach, it's definitely harder to fix these problems later, but "at scale" is that really a problem? The big problem is getting to the scale, surviving long enough.

Unless something has changed, I believe Instagram is still on Django

They are a heavily custom fork from a very old version of Django, but apparently much is still "recognisably Django".