BEAM There, Done That with Chris Beck - Why ETS and a single Rust NIF beat Go, Rust, and Node for a BlueSky-scale workload

New BEAM There, Done That episode worth a read for anyone who’s had to defend an Elixir choice against teams pushing for Go, Rust, or Node on benchmark grounds alone.

Chris Beck (Bitcrowd, Berlin) walks through building an open source alternative to BlueSky’s data plane: the part of the AT Protocol stack that turns the firehose into an actual timeline a mobile app can render. Target: millions of users, ~10,000 messages/second, with real spikes already observed (six million active users during the November 2024 US election).

The team genuinely expected to land on Go, Rust, or Node, all four being languages they use daily. Each got ruled out for structural reasons rather than raw speed: Go’s GC pauses would have been a permanent tuning problem, Rust’s safety guarantees came at the cost of iteration speed they needed for a side project doing constant experimentation, and Node’s single-threaded scheduler is exactly why BlueSky’s own production team already moved away from their reference implementation.

What made Elixir work despite losing almost every microbenchmark:
ETS handled storage and follow-graph lookups at C speed without needing a NIF, covering most of what would otherwise have been Elixir’s weak spot. For the one genuinely hard case, bitmap computation for the “social proof” / mutual-follows feature, they reached for a Rust NIF via Rustler. They’re candid about the cost: a NIF runs in the BEAM’s own memory and a crash there can take the whole VM down, unlike a regular Elixir process failure.

The fan-out architecture, pushing messages directly into user mailboxes on arrival, gave them natural backpressure and burst absorption with no external queue needed, something they note would have added network and serialization overhead in any of the other three stacks.

Chris’s one-sentence takeaway for anyone choosing a stack: ignore what seems obvious on paper, start from a shopping list of actual requirements, and look at what genuinely cannot be solved any other way before deciding.

The project is open source, documented at bitcrowd.dev, and the team is actively looking for collaborators.

5 Likes