3 ms·
Hello, OP here. Yes, I was intentionally abstract because I thought I was writing to a smaller audience of people who had spent some time with Elixir/BEAM. I ne
by ggv 6y ago
Hello, OP here. Yes, I was intentionally abstract because I thought I was writing to a smaller audience of people who had spent some time with Elixir/BEAM. I never expected the attention this has received!
In my 25 year career, I've been paid to work in Lotus Notes, Java, C#, Javascript, Ruby, Clojure, and now Elixir. My employer's system is basically an integration platform. We perform background tasks on behalf of our customers that access 3rd party APIs, our database, and then decide to push some data to other systems. We do have a web interface that is mostly the status of this background processing, plus a UI for when the users need a manual action.
There's other great replies touching on your technical questions, but here's my brief angle on it. BEAM processes are as isolated as OS processes, but they are very quick to spawn and need very little memory. A typical developer-caliber laptop computer can probably support on the order of a quarter million processes. Their isolated nature is supported at all levels of the design of the BEAM.
- QuadrupleA 6y agoThanks - appreciate the reply (and the other helpful replies here too). I've done a fair bit of threaded / async stuff in Python / C / JS - sounds like BEAM processes are more baked into the language & runtime and encouraged as an architectural style, rather than an added complexity you bargain with when you hit a single-threaded performance wall. Interested to do a deeper dive on it sometime.