WhatsApp had less than 50 engineers (or was it employees total?) when Facebook bought them out, and they had millions of users.
Suppose Flutter may be an order or two magnitude more complex than cURL.
Which boils down to: Number of devs vs. people using something is a very bad metric. Even number of supported devices won't work good in this case (I assume cURL runs basically everywhere).
I think it's very difficult to estimate complexity, and then make a statement about "how many people are enough" is even more difficult. Some environments are harder and more complex, some are just very heterogen and some are both. Sometimes it's the organizational overhead, maybe even something else.
plus they said an "order or two" which would be 10-100x so ...
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
What sets professional Python aside from most other programming languages is that everyone who uses it knows that it’s terrible and how to deal with that. Which will sometimes be replacing parts (or all) or it.
To say that it’s inherently less performant than JS is frankly silly though.
CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector. CPython is way, way simpler than V8, but it's consequently slower. It's just the consequence of Google putting centuries of developer-years into an engine.
You can't just claim Python is fast because Python's C libraries are fast. Those libraries are fast despite Python. Torch is extremely fast, but it's fast from C and Lua too. There's valid reasons to want to compute in your programming language. Python is, ironically, probably popular because its slow speed encouraged users to write blazing fast C libraries rather than even try writing native Python, vs. settling for middling performance as in Java or .NET.
I shouldn't have to get out my hammer and tongs when NumPy doesn't implement the operator I need. Why can't Python be fast like Julia?
Python 3.13.0: 799.6559143066406 ms
Node 18.20.4: 59.34080000221729 ms
Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.
Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.
We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.
Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.
power(Python) > power(Erlang)?