> Now you can write regular blocking code, but the executor will take care of moving your process off the execution thread if you are waiting, so you never block a thread.<p>This is super important and awesome. It's a big part of what makes Erlang simpler to write code for than other highly concurrent environments.
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>> In most cases it'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're handling IO. What I see rarely discussed here is forms of non-blocking IO and why those haven'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'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's wrong with having a thread pool combined with non-blocking IO ?
Bastion [1] is also inspired by Erlang and provides many of the features described in this post. Although it does not compile to Wasm, it provides:<p>- Message-based communication<p>- Runtime fault-tolerance - a lean mesh of actor system.<p>- A Supervision system that makes it easy to kill or restart subprocesses<p>Does anyone have experience with Bastion or other Rust actor systems?<p>1: <a href="https://bastion.rs/" rel="nofollow">https://bastion.rs/</a>
So I am very fascinated by both languages and work in Elixir professionally, with a pretty minimal knowledge of Rust. I was just wondering what the motivation for creating this project was rather than just writing the application in Elixir with NIFs in Rust whenever higher performance is needed?
The submitted link does no longer for me, here's a link to the original article: <a href="https://dev.to/bkolobara/writing-rust-the-elixir-way-2lm8" rel="nofollow">https://dev.to/bkolobara/writing-rust-the-elixir-way-2lm8</a>
Hi, can you please explain the Wasm part? Is there any particular reason to use Wasm? I don't know wasm but does it use a specific threading/concurrency mechanism in it?
>"Even though the threads don't do anything, just running this on my MacBook forces it to reboot after a few seconds. This makes it impractical to have massive concurrency with threads."<p>That is a problem of your MacBook. I can run thousands of threads when testing some servers sustainably and with no problems on my Windows and Linux laptop, never mind desktop and real servers. So it is pretty much practical. Whether it makes sense pretty much depends on what are you doing in particular. Your conclusion means zilch without context.
To me, this looks <i>extremely</i> promising from a performance and developer ergonomics point of view and a fantastic use case for WASM and WASI - only limiting factor seems to be the rollout for WASI networking support.
> but I will call them processes to stay close to Elixir's naming convention.<p>That seems like an extremely confusing mistake given that there is already a very closely related concept called a "process"?<p>I would consider calling them "workers" or "isolates" since unless I'm mistaken, you have basically recreated WebWorkers (AKA isolates in V8/Dart)?<p>Presumably this also means you can't share memory? Very neat idea anyway!