How's that different than using a well defined binary serialization format (protobufs?) and having a controller daemon that makes sure everyone reports the same version or has the same serialization contracts loaded before adding them to discovery?
Or is it just that Erlang has this all batteries included, the way Python's popular with scientific programming?
You are spot on. You can do what Erlang does in many ways. It's the combination of all this, built into a coherent architecture, that makes OTP unique.
The reason this thread exists is because other options with strong ecosystems and better performance which accomplish the above mentioned stuff just don't seem to exist.
I'd actually love to see some performance numbers comparing performance on Erlang/OTP vs the alternatives, though. I can't find anything quite like that, maybe someone knows a link.
Similar solutions exist everywhere, which is partly why the Erlang ecosystem is so small!
But I agree that Erlang's design is beautiful, which is why I've decided to port it to the JVM with Quasar. I wanted to bring that great design to a more powerful runtime and a much bigger ecosystem. Again, the problem isn't with the Erlang language but with the runtime that, while really nice, simply does not have nearly enough resources to compete with the bigger runtimes like the JVM and .NET (or even V8).
We will have some benchmarks eventually, I promise, but those take a long time and aren't too critical, because, like I said, the Erlang ecosystem is very small.
P.S., in case that wasn't clear: Erlang's design is absolutely brilliant -- it's inspired -- but the implementation suffers from insufficient resources. The result is lagging performance and a small ecosystem.
Or is it just that Erlang has this all batteries included, the way Python's popular with scientific programming?