So now you need several servers, an orchestrator, tons of YAML, arcane and terrible error messages and a devops team to kind of match the BEAM? That's... not a good look
Yes. This is a big part of what initially drew me to Elixir. It's more than feasible to run a server on a cheap VPS, get great, though not quite Golang or low-level language performance and have a much easier scaling story when you need multiple machines.
More importantly, you generally don't need an external queue service, in-memory KV store, task scheduler or many of the other things that JS/Ruby/Python stacks need. By consolidating just about everything but the DB in a single, well designed system, it's possible for a very small team to take on relatively large challenges on a smaller budget.
Where does your Erlang code runs in the first place? ( maybe kubernetes already )
Kubernetes does all of that in a standard and easy way but also is completely language agnostic. So your Python code without modidication can benefit from it.
> So your Python code without modidication can benefit from it.
that's not completely true though, say you have two python processes, you need to solve yourself how they communicate, HTTP? a message broker? through the DB? You need to handle errors, stateful deployments.
You can deploy python code without modification if the python code does very simple things. My point is that the BEAM gives you a lot of this mostly presolved for you without having to add more infrastructure.
You can use a BEAM system to orchestrate other code, too. As ports, port drivers, nifs, c-nodes, just other OS processes spawned and using IPC/sockets. Lots of options. Using Erlang to supervise an OS process doing work perhaps enhances the isolation principles of BEAM.
To add to that, the BEAM has binaries as a data type so when you're talking to a foreign program you can quickly prototype or design binary protocols once you get tired of parsing/encoding JSON or XML or something at the edges. Depending on the facilities of the foreign language it might be more or less feasible, of course.
It's snarky but I think it is a fair comparison. You do have extra capabilities over what BEAM offers, in exchange for having to manually handle a lot of things BEAM either handles invisibly or at least comes with usable defaults for.
More importantly, you generally don't need an external queue service, in-memory KV store, task scheduler or many of the other things that JS/Ruby/Python stacks need. By consolidating just about everything but the DB in a single, well designed system, it's possible for a very small team to take on relatively large challenges on a smaller budget.