Learn

Erlang's killer feature is distributed by design. A process on a remote node looks identical to a local one.

Starting a node with a name:

$ erl -name node1@host -setcookie secret
$ erl -name node2@host -setcookie secret

Nodes with the same cookie can talk to each other.

Connect:

%% On node1:
net_kernel:connect_node('node2@host').
nodes().    %% [node2@host]

Spawn a process on another node:

Pid = spawn(node2@host, fun() ->
    io:format("running on ~w~n", [node()])
end).

The Pid is a remote PID. Sending to it via Pid ! Msg works exactly like a local PID — the runtime serializes and ships the message.

Globally registered names:

global:register_name(my_server, ServerPid).
%% Anywhere on the cluster:
global:whereis_name(my_server) ! some_message.

The global module gossips registrations across nodes — every connected node knows about every global name.

rpc:call for remote function calls:

rpc:call(node2@host, math, sqrt, [16]).    %% 4.0

Mnesia distribution — the killer DB feature. Tables can be replicated across nodes, with automatic failover. Set up with mnesia:create_table + disc_copies / ram_copies per node.

Failure semantics:

• A remote call to a downed node returns {badrpc, nodedown} (or similar)
• monitor_node(Node, true) fires a {nodedown, Node} message when the node disconnects
• Linked processes propagate exits across the network

Real systems:

• WhatsApp ran 2M+ TCP connections per node for years using vanilla Erlang distribution
• RabbitMQ clustering uses Erlang distribution under the hood
• CouchDB uses it for its multi-master replication

Caveats:

• Erlang distribution assumes trust — set proper cookies + firewall
• For untrusted networks use TLS-enabled distribution
• Designed for LAN — not necessarily great over WAN

For Judge0, single-node scripts are what we run. Real distributed Erlang requires a multi-node cluster setup.