[anko]

I find the "high throughput" comment a bit weird, but i've seen it a lot of times. Do you mind drilling into it a bit more?

I see posts like this https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b where they are talking millions of events per second.

I also work in the distributed messaging space and so far my experiments have shown elixir to be able to keep up with our scala stack with the advantages of no thread tuning and much easier debugging. So I'm curious why this keeps popping up.

[verttii]

My point was rather that that's where Elixir excels.

Throughput is always a compromise with latency in garbage collectors and schedulers.

Elixir prioritizes low consistent latency with its garbage collector and preemptive scheduling. Whereas many other systems, such as Haskell's GHC compiler/runtime prioritize high throughput instead for better computational performance.

All the computations have to run inside a process in Elixir. Erlang's platform constrains each process so that any single process cannot hog all the resources available. Therefore, you need to split the computation to many processes when you do CPU intensive work. And processes carry message passing overhead, leading to reduced maximum throughput.

Something like lots of small messages with minimal processing (think: chat) over a bunch of network connections sounds like the ideal sweet spot for Elixir.

[elcritch]

Perhaps it’s in reference to compute throughput or disk io? BEAM doesn’t do quite as well in those areas. Not bad but ok. I just did some micro benchmarks on matrex compared to numpy and surprisingly the Elixir nif’s were about 10% faster on my MacBook. Dirty threads have helped nif’s on providing compute throughput too.