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.
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.
AlchemistCamp|9 months ago
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.
da02|9 months ago
Thaxll|9 months ago
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.
MarceColl|9 months ago
> 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.
tough|9 months ago
toast0|9 months ago
giraffe_lady|9 months ago