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.
It may be wrong to say we need a better Erlang, but for modern web development we certainly could use a fair bit more compiler enforced type safety for writing more correct programs. Mostly due to the lack of a proper type system, Erlang is not particularly expressive as a language, although its primitives (processes & message passing) are well geared exactly for what it focuses on.
Erlang focuses strongly on fault-tolerance and subsequently on high availability, but I'm not sure this perk is so significant benefit anymore compared to various other runtimes spinning the wheels of your typical web server in a cloud setup. We rarely need to write servers anymore that keep running for many years straight without a restart, only patching code via hot reloads.
Just my take but since you asked, trading some fault tolerance for more correct programs would therefore probably be a fair trade-off for a new kind of Erlang.
- Strong static typing. It's 2020 and we should all stop pretending that it doesn't eliminate class of bugs. It does.
- Goes without saying since we mention Erlang but still -- full async support for both CPU and I/O intensive tasks. If one actor goes 100% CPU in an infinite loop everybody else should be unaffected (as much as the hardware allows for that). And if the compiler itself can detect infinite loops and just yell at you for them, even better! (But that borders on sci-fi at the moment.)
- Again related to the above: full non-voluntary preemption. You can insert your own yield points if you like but the runtime will choose if it will respect them or not.
- Obviously, raw speed. I love Elixir and with time I learned how to make its code minimally intrusive for the CPU -- most of my Elixir code basically glues things together, does a quick processing and gets the hell out of the way. 100% of my Elixir code always waits on DB or network requests and I am very proud of that. Still, I'd love such an amazing concept like the actor style parallelism and all the BEAM's goodies in general to come in a package that's 10x or 100x faster and make full use of modern hardware! SIMD / AVX included.
---
There could be more but these are just off the top of my head.
A much shorter answer would likely be: a BEAM VM with minimal memory and I/O and CPU overhead, fully utilising the hardware, and bringing correctness and less bugs with strong static typing.
Making it faster for certain things, as long as that doesn't hurt it in other ways, is always going to be a win.
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://pragprog.com/book/pb7con/seven-concurrency-models-in...
https://github.com/bastion-rs/bastion/tree/master/bastion/ex...
