[tomekowal]

Short answer: scheduler.

Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late...

With:

- per process garbage collection

- one BEAM process per request

- short lived HTTP processes

you might never trigger garbage collection, the whole memory is deallocated at the end of requests.

It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language.

This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P)

And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time.

And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.