Isn’t the issue, though, how do you scale this out? HTTP app servers are great... you can add and remove them at will, based on load, and customers never know the difference, because it only takes a few seconds after not accepting new connections for the existing ones to drain.

If you instead have servers holding state, those servers become a lot less ephemeral.

In addition, HTTP has built in caching, which is a HUGE benefit for scale.

dnautics isn't wrong. Even the issues you bring up are addressed by Erlang/OTP. Distributed Erlang with 10K nodes, hot code reload, etc.

the only people who think distributed erlang is good are people who have never done anything nontrivial with it

Could you explain why that is to someone (me) has never done anything nontrivial with it? Thanks.

i'd encourage everyone thinking about using it to go read the code (it's fairly approachable) but in short it just connects each node in the cluster to each other node in the cluster via a tcp connection and sends packets between them. there's almost nothing as far as protocol, queue management, congestion control or traffic management. it's discovery mechanism is just shipping lists of peers around. pretty much any competent programmer with networking experience could put together something comparable

it works okay in small clusters on reliable low latency networks but it's not a replacement for an actual network mesh

there have been attempts to fix it but none have really found adoption. i think this is the most notable: https://lasp-lang.readme.io/docs

thanks for your answer so basically it relies on plain TCP and its reliability features. If you need something more sophisticated you gotta do it yourself within the application code (or using libs).

Elixir tends to have sophisticated libraries around what you really want that are plug and play with distributed erlang. (Phoenix pubsub/tracker/presence). Horde/swarm, etc.

I work on a system with an distributed erlang service mesh.