Foreward

Fluxion exists to fulfil a very specific usecase: an actor library that can send messages between systems. How these systems are connected does not alter the behavior of Fluxion, nor should it matter to actors running on a Fluxion system. Fluxion is also different from traditional actor libraries in that it does not provide actors mutable access to themselves, nor does it provide "fire and forget" messages.

Fluxion makes both of these restrictions in the name of performance and extensibility. If Fluxion were to allow actors mutable access to themselves, Fluxion would need to implement a layer of synchronization on top of each actor. This needlessly harms the performance of actors that do not need mutable access. Additionally, actors that do need mutable access to themselves can simply implement their own synchronization where needed. Fluxion doesn't provide "fire and forget" messages, because it would require a dependency on a specific async executor. This is because Fluxion, via Slacktor, uses a "simulated messaging" system where raw function calls are used instead of channels. This significantly increases performance. If "fire and forget" messages are required, a user can implement them by spawning a new async task to send the message from.

Importantly, Fluxion is not an actor framework, but an actor library. Fluxion will not force your entire application to be designed following a specific pattern, and can be used as much, or as little as you want.

Due to Fluxion's limited scope and architecture, it tends to be very performant, especially when compared to other actor frameworks. Running the benchmark example (which is designed to test Fluxion's raw performance, not necessarily the performance of the actual actors implemented), Fluxion acheives a throughput of ~60 million messages per second on an intel i5-9400 compiled with release. The equivalent code running on Actix can only handle ~700,000 messages per second.