Actix is a rust actor system and web framework. Let’s discuss it in general (if someone in the community have used it and have more knowledge about it), and also if it can be brought to Elixir as a NIF to replace or assist the BEAM’s actor model to boost performance.
1 Like
The BEAM does not implement an actor model, and is highly optimized for concurrency. I doubt you would gain significant performance while keeping all the current features of Erlang processes.
Also worth reading.
4 Likes
I suspect it wouldn’t be easy to integrate - Actix uses the Tokio reactor, which is (roughly) equivalent to the BEAM scheduler. Both generally assume they are “THE event loop”.
You’d also have to keep in mind the issues with long-running NIFs, described here
A fairly advanced option would be to build a custom tokio::reactor::Reactor implementation that uses the BEAM scheduler to dispatch Rust futures.
OR
Another option: use the C Node bindings to make an “Actix node” where Rust actors live and communicate with other BEAM nodes.
5 Likes
This is what I would do. Since the BEAM in general is not intended for raw performance I’d guess that having a highly performant node that speaks the Erlang node protocol is the much less painful approach.
OTP is quite adequate for a lot of stuff. If you need raw speed, just spawn a node that can integrate with it and is written in a faster language.
1 Like
I’m working with Actix some now, and I honestly don’t see the usefulness of integrating it with Elixir. What would be the point of having a cooperative scheduler running inside the BEAM’s scheduler???
Now, coding performance-sensitive bits in Rust makes sense. Maybe even using async I/O & futures to help structure potentially long-running calls.
3 Likes
