Thank you for your detailed message. I haven't understood everything you wrote but it seems that basically all that complexity comes from supporting hot code reloading.
Given that a lot of (most?) Elixir devs don't use hot reloading, having a less powerful but simpler deployment alternative seems like a good idea.
Erlang is in the weird situation of its main code contributor, Ericsson, having a use-case for it that very few other people/organizations have: “immortal” nodes running code approximately forever, on telecom control-plane boxen.
That means hot-code reloading (or at least doing something to let the node receive upgrades while keeping live sockets open) is a high priority for them, and so the OTP (Open Telecom Platform) Erlang RunTime System is always going to be designed around that goal.
We third-party Erlang/Elixir developers, are all essentially using a recovered alien artifact. It was built for people very different from us, for purposes foreign to us. As it happens, though, it’s very advanced alien technology, such that it’s often able to solve our problems very well, despite not being designed to solve those problems. Our use-cases are very often strict subsets of those of our Swedish telecom overlords.
And, given that that’s the case, there’s not been much motivation to build a separate ERTS to serve us mere mortals deploying merely-mortal Erlang nodes. We don’t really need different ERTS, just less ERTS.
I could see someone maintaining a patcher program that takes the OTP repo, and strips out all the stuff us mortals don’t need. But that wouldn’t really be an alternative ERTS. It’d be the “XPLite”-ization of OTP.
And really, if you try to think of who would lead an effort to develop an alternative “closed-world”-design ERTS, you come to the realization that ERTS and actors and hot code-reloading all sort of occupy the same area of use-case space, such that AFAIK there’s no real use-case that absolutely needs most of what Erlang has, but absolutely doesn’t need hot upgrades. If you try to think of a scenario where there’d be absolutely no use for hot upgrades, that’s also probably a situation where Erlang/Elixir, or the actor model itself, would likely be a bad fit. Unikernels (Erlang-on-Xen)? Nah, hot upgrades make sense there. Long-running embedded microcontrollers (Nerves)? Nope, hot upgrades make sense there too.
Really, if you want “Elixir but closed-world”, the place I’d expect to get it is if someone wanted to reimplement Elixir-the-language on top of an entirely different runtime, e.g. the JVM. Elixir-on-JVM would imply Elixir-on-GraalVM, which is just such a closed-world runtime.
Given that a lot of (most?) Elixir devs don't use hot reloading, having a less powerful but simpler deployment alternative seems like a good idea.