[jkot]

For this I would go with some J2EE or clustered framework. Erlang is nice, but is outdated and does not handle clustering that well. It is about migrating clients and threads, while multiple versions of the same library exist within system.

> The size of the code deployed matters

And I disagree with this. The hardest deployment I ever seen was 2KB of code. Sim toolkit is impossible to modify once it is flashed into 2 million SIM cards. :-)

[hassy]

In what sense does Erlang not handle clustering well? It's true that you wouldn't run a "native" (ie EPMD-based) cluster of hundreds of nodes, but what would stop you from implementing a clustering architecture you'd build with, say, J2EE in Erlang?

[vezzy-fnord]

Erlang is nice, but is outdated and does not handle clustering that well.

Erlang's distribution was always designed for redundancy and fault tolerance first, thus features like location transparency and heartbeats across nodes. There is no inherent service discovery mechanism built in (tools not solutions), and I suppose large topologies could benefit from third-party process registries.

I'd hardly call it "outdated", just that its default mechanisms for organization are a little different.