[erlang-questions] "Erlang, the next Java"

[Ulf Wiger]

2007/8/10, Chris Wong <chris@REDACTED>:
>
> I was reading the doc on this.  It's consistent with what you say
> here.  Basically, if you have to wait for thousands of Erlang nodes
> to establish communications with each other before you it can do
> anything, the whole will crawl to its knees when one node is down.
> Correct me if I'm wrong.

If you're going to build a distributed system that makes use of
thousands of nodes, you have to make it very loosely coupled,
and make sure that you use localized communication patterns
(refrain from using broadcasts and global voting mechanisms,
for example). This takes a lot of planning.

Erlang's distribution concept is based on loosely coupled nodes.
There are a few libraries that default to "connect-all" semantics
(global comes to mind), but you don't have to use them. You can
turn off the behaviour that erlang automatically tries to connect
to a node as soon as one sends a message to it. Since it's quite
easy to make your own tcp-based rpc mechanism (or similar), you
can create clusters of Erlang nodes which connect to each other
using some other form of communication (say, ORBER, which comes
with OTP).

If you want just 1000 CPUs, why not connect 32 nodes, each using
32 cores? Then you don't even have to resort to trickery.  ;-)

It obviously depends on exactly what application is going to make
use of this many CPUs, but the fact that Erlang makes it easy to
build small distributed systems by offering lots of convenient features,
is not in itself proof that you can't build much larger systems by
avoiding the patterns that don't scale well. They _are_ optional.

BR,
Ulf W