I think another way to frame my question would be: which is the basic unit of parallel execution in Bastion? A thread? Or a separate process? There are mentions of lightweight processes and subprocesses in the README but it is rather vague what these are.
An actor is:
1. A lightproc, which, per my understanding, are async-spawned threads returning (optional?) Futures [0].
2. A ProcHandle [1] that lets you define process-state (like pid), control process-exec (like cancel, suspend?), listen on progress of a given lightproc that is run by BastianExecutors [2], whilst the message passing / supervisor semantics is handled by Bastion [3].
https://akka.io/ on JVM would be a better comparison to this than BEAM's implementation of actors, I think.
[0] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...
[1] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...
[2] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...
[3] https://docs.rs/bastion/0.3.4/bastion/struct.Bastion.html
https://docs.rs/bastion/0.3.4/bastion/macro.msg.html
Seems less clean to read than Riker (https://riker.rs), though that doesn't really do async well.
The Getting Started example gives some useful insights:
https://github.com/bastion-rs/bastion/blob/master/bastion/ex...
Origin title: `The missing part of actor-model programming in rust`.
If it's 'Erlang for Rust developers' I'd be curious to get a feel for how well it integrates with everything. A lot of what Erlang does is kind of difficult to shoehorn in via a library, but I don't know Rust well so maybe it all integrates in a very natural way.
1. https://github.com/actix/actix 2. https://github.com/rsimmonsjr/axiom
In concurrent programming, there are a few mental models/approaches you can use to achieve it. Each of them have different "values systems" and tradeoffs, if you will.
In a nutshell, you have:
- Locks (Mutex/Semaphore)
- Communicating Sequential Processes
- Software Transactional Memory
- Actor Model
The Actor Model is a particularly powerful paradigm because it isolates processes and works via message passing and spawning. The reason why Erlang/Elixir are fault-tolerant is because of the BEAM's process model, any given process (more or lesss) can fail and it's not a problem due to isolation.
What this library allows you to do is architect applications in ways such that they are much more resilient to failure and easier to scale out + parallelize/distribute.
It doesn't have to be a networked application either, any code process can be an actor. It applies to any software.
If you want a great overview of the Actor model, there are some slides here which do a fantastic job of illustrating it:
https://cs.nyu.edu/wies/teaching/ppc-14/material/lecture10.p...
https://github.com/bastion-rs/bastion/tree/master/bastion/ex...