[jimbokun]

Erlang pushes kubernetes down into the language and its libraries, instead of requiring Docker images and containers, etc.

This means that the processes can be much, much more lightweight than kubernetes pods and containers. Cheaper to kill and restart. Can provide concurrency and fault tolerance at a far more granular level. Much simpler to write and deploy than Docker images. Etc. etc.

At least that's my understanding (significant work experience with kubernetes, no real production experience with Erlang/Elixir).

[OkayPhysicist]

As an dev working in Elixir, you're right on the money. IMO, the biggest benefit you gain from that granularity is that since processes cost next to nothing to spin up and down, you can (ab)use your fault tolerance mechanism for error handling, leading to the famous "Let it crash" philosophy.

Restarting your docker image every time someone sends a malformed packet to your webserver is going to make for a trivial not even D-DOS attack. Killing the individual process that spins up to handle that particular packet/connection, though, is simply best practice.

[Thaxll]

Except you still need to run and deploy your Erlang app somewhere which might end up on Kubernetes.

Kubernetes is just better than Erlang for process managment because it does more and is completely language agnostic, imagine you can't build some part of your system in Erlang but you need the same kind of functionality what do you do?

[calo_star]

Depending on the size of your component that can't be built in Erlang, you may be able to use NIF and throw it on the dirty scheduler.

[mapcars]

You can make NIF, you can implement Erlang protocol to talk to the node (and I have done it). Both of those are possible but does it worth it in the end? Is it worth to have orchestration builtin into the language and locked with some particular features instead of a full-fledged devops setup? The only argument I have is in early stages of development it might save some time.