Writing Rust the Elixir Way
Love Erlang and Elixir and Beams concurrency model is quite interesting. This Rust variant seems very interesting as well. But I wanted to discuss this part:<p>&gt; In most cases it&#x27;s enough to use a thread pool, but this approach fails once the number of concurrent tasks outgrows the number of threads in the pool<p>I think something has been lost from all the dialogue about concurrency. The only way the number of concurrent task can outgrow the number of threads is when you&#x27;re handling IO. What I see rarely discussed here is forms of non-blocking IO and why those haven&#x27;t become the norm. Why are we all trying to work around models that involve blocking on IO? I feel I almost never hear about using non-blocking IO as an alternative?<p>For all other tasks which involve computation, thread pools are needed to improve throughput and performance, only threads can be executed in parallel. Yes you can still multiplex many more small compute task over many threads, if you wanted a really responsive but overall slower program, that could be an option, but I think most people going for a concurrent approach aren&#x27;t doing so for that, but really just as a way to leverage their IO cards to the fullest.<p>So my question is, what&#x27;s wrong with having a thread pool combined with non-blocking IO ?