No account, no password. The server identifies you by your connection, not by anything you type here.
Whoever created can send you a link that fills this in automatically.
Leave the code blank for an open room. Set one and only people with the code (or your invite link) can get in.
This is a small chat server, but it is built the way Erlang wants you to build things. Each of the three buttons in the sidebar runs a real demonstration on the real server while you are chatting, so none of this has to be taken on trust.
Every browser tab connected here is its own Erlang process, with its own memory and its
own mailbox. Not a thread, not a callback, not a row in a session table. Each room is a
process too. Sending a message to a room is literally Pid ! Message, and the
room's member list is a map of process id to nickname, so broadcasting is a loop over
that map. There is no delivery layer to write.
This works because Erlang processes are not OS threads. They start in microseconds and cost a few hundred bytes each, so "one per user" is an affordable design rather than a luxury. That is the reason Erlang keeps turning up in chat, messaging and telecoms.
procs counter in the header spike and settle. On a Raspberry Pi.
The room you are in is a process, and Crash this room kills it outright with
exit(Pid, kill), which cannot be caught or cleaned up after. Every other room
keeps running untouched, because they are separate processes with separate heaps: one
cannot corrupt another's state.
Your browser gets put back into a rebuilt room within milliseconds, and nobody wrote a
recovery routine for it. Your connection process was monitoring the room, so it
gets a DOWN message when the room dies, asks the directory to rebuild it, and
rejoins. The same mechanism handles you closing this tab: your process dies, the room gets
a DOWN, and you disappear from the member list. There is no heartbeat, no
session timeout, and no stale-user cleanup job anywhere in this codebase.
That is what "let it crash" actually means. Not that errors are ignored, but that you stop trying to defend every function against every possible failure, and instead make the blast radius small and the rebuild automatic.
Peg the CPU starts processes running tight infinite loops for three seconds. They never sleep, never wait on a socket, and never voluntarily give up control. Keep typing while it runs: the chat does not stutter.
Erlang's scheduler is preemptive. It counts work units, called reductions, and forcibly switches processes out whether they like it or not. In a runtime with cooperative concurrency - Node's event loop, Python's asyncio - a single loop like this blocks the whole server and every connected user freezes until it finishes. Here it is just another process being scheduled among thousands.
The demo measures this rather than asserting it: a probe process tries to wake up every millisecond during the burn and reports the worst delay it saw.
chat_room.erl is the room process, and the entire disconnect handler is one
DOWN clause. chat_ws.erl is one process per browser tab, and
holds the monitor-and-rebuild logic. chat_directory.erl owns room metadata
and pushes the stats in the header. chat_demo.erl is the three buttons.
The whole server is about 700 lines.