Erlang/OTP - The Weird Functional Language That Handles Millions of Connections

What Actually Is This Thing?

Erlang came from Swedish telecom engineers in the '80s who were pissed off that their phone switches kept dying. When a telecom switch goes down, you lose millions per minute, so they said "fuck this" and built a language where things are allowed to crash without bringing down the entire system.

The syntax looks like someone took C and ran it through a blender with Prolog. I spent 3 weeks cursing at semicolons vs periods - they're backwards from literally every other language. You end clauses with semicolons and functions with periods, which feels wrong until your muscle memory finally gives up fighting it.

But here's the kicker: spawning an Erlang process costs less than creating an object in Java. No joke - 2.6KB of RAM and you get your own isolated universe with a mailbox.

The Actor Model (But Actually Useful)

Each process is completely isolated - it has its own memory heap, stack, and message queue. When one crashes, it doesn't take down anything else. I learned this the hard way when I spawned way too many processes on my MacBook (maybe 2 million?) and everything kept running fine. Try that with threads and see how fast your OS starts weeping.

The BEAM VM can theoretically handle millions of processes, but in practice you'll hit other limits first. I've run systems with 100k processes without breaking a sweat - the scheduler is fucking magical at keeping everything fair.

Forget those synthetic benchmarks claiming millions of messages per second. Real production systems with actual payloads? Maybe 20-40k messages/second if you're lucky and everything's optimized. Network I/O will be your bottleneck way before the VM gives up.

Who's Actually Using This?

OTP 28.0 dropped in May 2025 with some decent improvements. They've been pretty consistent with yearly releases, which is nice when you're not dealing with the JavaScript ecosystem's "new framework every Tuesday" bullshit.

Here's who's actually betting their infrastructure on this weird functional language:

• WhatsApp: 32 engineers handled 450 million users before Facebook bought them for $19 billion. That's roughly 14 million users per engineer. Try scaling that with Node.js.
• Discord: Actually switched from Go to Rust because their garbage collector was causing random latency spikes during message fanout. They didn't go with Erlang/Elixir, but the problem they solved is exactly what BEAM languages excel at.
• Goldman Sachs: Uses it for high-frequency trading where a millisecond delay costs millions. If Goldman trusts it with their money, maybe it's not just academic masturbation.
• CouchDB: The entire database is written in Erlang because they needed something that doesn't shit itself when things go wrong.

The "Let It Crash" Philosophy (Sounds Insane, Actually Works)

Most languages teach you to catch every exception and handle it gracefully. Erlang says "fuck that" and just lets things crash. Sounds stupid until you realize that process isolation means one crashed process doesn't take down everything else.

When a process dies, its supervisor restarts it in milliseconds. I've seen production systems restart 10,000 processes without dropping a single user connection. Try that with your REST API built on Express.

Hot code reloading is pure magic when it works. You can literally update running production code without stopping the system. But I once accidentally updated the wrong module and all user sessions got corrupted because the state format changed mid-flight. The docs say it's "safe" but always test that shit on staging first.

Installation and Setup (AKA Your First Frustration)

Download OTP 28.0 - though in my experience, half the time the installer is broken on whatever OS you're using.

Linux: apt-get install erlang works 90% of the time. When it doesn't, you get cryptic dependency errors about libssl1.1 vs libssl3 that'll waste 2 hours of your life. Ubuntu 22.04 users: OTP 25.3 breaks SSL connections randomly - use 25.2 or 26+.

Mac: brew install erlang usually works, but on M1 Macs you might get this fun error: beam.smp: Bad CPU type in executable. Solution: uninstall everything and use the native ARM build. Pro tip: OTP 24.x has threading issues on Apple Silicon - go straight to 25+.

Windows: Just fucking use WSL. Seriously. I've seen grown developers cry trying to get Erlang running on Windows 11. PATH variables become your enemy, and erl command not found is basically guaranteed. If you absolutely must use Windows, OTP 27+ has better native support but you'll still hate life.

The REPL Will Teach You Or Break You

The Erlang shell is great when it works, but it'll crash more often than Windows Vista. Syntax errors give you cryptic shit like:

** exception error: no match of right hand side value {error,eacces}

What the fuck does that mean? Usually you misspelled something or forgot a period somewhere.

Pro tip: Always keep a backup shell open. I once spawned a million test processes in the REPL and locked up my entire session. Had to kill -9 the whole BEAM VM and lost 2 hours of REPL history.

Pattern Matching Will Hurt Your Brain

factorial(0) -> 1;
factorial(N) when N > 0 -> N * factorial(N-1).

See that semicolon vs period? I still fuck this up after 2 years. Mix them up and you get beautiful error messages like:

syntax error before: '.'

Super helpful, right? Semicolons separate clauses, periods end functions. Remember that or prepare for pain.

Variables start with capital letters, atoms with lowercase. This is backwards from every other language and will fuck with your head for months. I still occasionally write User when I mean user and wonder why my pattern matching is broken.

OTP: The Magic You Don't Understand Yet

GenServers are like classes if classes had mailboxes and could crash gracefully. They handle state automatically, which is amazing until your server gets stuck in an infinite loop processing the same message forever.

Supervisors restart your crashed processes, but the strategy matters. I learned this around 3am when I used one_for_all instead of one_for_one and crashed our entire user session cluster. One broken authentication process took down maybe 15k connected users. Took the system half an hour to restart everything and users were pissed.

The error I got? Just this helpful message:

=SUPERVISOR REPORT==== 11-Sep-2024::03:xx:xx ===
supervisor: {local,session_sup}
errorContext: shutdown_error
reason: reached_max_restart_intensity

"Reached max restart intensity" - gee thanks, super specific.

Performance Reality Check

WhatsApp's numbers came after years of optimization and custom kernel tuning. Your first Erlang app will not handle 450 million users. Mine crashed at 10k concurrent connections because I didn't configure TCP buffer sizes properly.

Ignore those synthetic benchmarks claiming millions of messages per second. In production with real JSON payloads and database calls, expect maybe 15-30k messages/second if you're good at this. Network I/O kills performance way before the BEAM VM gives up.

The BEAM Ecosystem (Choose Your Poison)

• Elixir: Same VM, readable syntax. Use this instead of Erlang unless you hate yourself.
• Gleam: Types everywhere, still too young for production. Check back in 2027.
• LFE: Lisp on BEAM. For people who think Erlang syntax isn't confusing enough.

Learning Curve From Hell

Expect 6+ months of pain. I've seen Java developers quit after a week because immutable variables broke their brains. Learn You Some Erlang is good but won't prepare you for production debugging nightmares.

Real war story: Spent 3 days debugging why messages weren't being processed. Turns out I was sending to user_manager when the process was registered as users_manager (note the 's'). The error?

** exception exit: {badarg,[{gen_server,call,[user_manager,get_user,5000],[{file,"gen_server.erl"},{line,261}]}]}

Just says "bad argument" - super helpful. You'll learn to trace everything with :dbg or go insane.