OTP provides the higher level abstractions to do what you are talking about. However, the BEAM VM itself provides a few features that when combined with the actor model and OTP, that makes it easier put together distributed system. Some of these are:
- Pre-emptible, lightweight processes that can be indefinitely suspended for relatively low memory cost.
- Immutable, copy-on-write for most data structures within the same lightweight process.
- Built-in queuing to support the Actor model (keeping in mind that this was designed before the Actor model was formalized)
- Generational garbage collection that avoids stopping the world or suspending the scheduler. (Avoids the garbage collection spikes seen in the Go runtime)
- Support for hot code reloading so live traffic can remain functioning. More important for telecom and stateful applications, and less fashionable now with the Kubernetes model of ephemeral workloads
All that taken together meant that you write the "distributedness" from the beginning, within the same VM, even though there are no network code involved. In other words, when writing Erlang/OTP code, you design for distributed computing in the very early stages, even if you initially deploy on a single node.
(Historical note: back before the BEAM VM supported multiple cores, people used to run separate BEAM OS processes per cpu and connected them together through network sockets on the same bare metal machine. These days, BEAM will automatically expand to use all the available cores of the machine).
Rust is already a fantastic partner for Erlang in the form of NIFs. Theoretically, a well-written Rust NIF can isolate memory errors and faults and would play nice with the rest of the app. NIFs have been historically problematic because they bypass these guarantees the BEAM VM makes for OTP apps and can be a source of crashers.
If Bastion has a similar runtime that has pre-emptible, light weight processes, that is very exciting. The rest of what BEAM provides involve guarantees around memory, something that Rust can provide in its own idiomatic way. (Except maybe the hot code reload).
- Pre-emptible, lightweight processes that can be indefinitely suspended for relatively low memory cost.
- Immutable, copy-on-write for most data structures within the same lightweight process.
- Built-in queuing to support the Actor model (keeping in mind that this was designed before the Actor model was formalized)
- Generational garbage collection that avoids stopping the world or suspending the scheduler. (Avoids the garbage collection spikes seen in the Go runtime)
- Support for hot code reloading so live traffic can remain functioning. More important for telecom and stateful applications, and less fashionable now with the Kubernetes model of ephemeral workloads
All that taken together meant that you write the "distributedness" from the beginning, within the same VM, even though there are no network code involved. In other words, when writing Erlang/OTP code, you design for distributed computing in the very early stages, even if you initially deploy on a single node.
(Historical note: back before the BEAM VM supported multiple cores, people used to run separate BEAM OS processes per cpu and connected them together through network sockets on the same bare metal machine. These days, BEAM will automatically expand to use all the available cores of the machine).
Rust is already a fantastic partner for Erlang in the form of NIFs. Theoretically, a well-written Rust NIF can isolate memory errors and faults and would play nice with the rest of the app. NIFs have been historically problematic because they bypass these guarantees the BEAM VM makes for OTP apps and can be a source of crashers.
If Bastion has a similar runtime that has pre-emptible, light weight processes, that is very exciting. The rest of what BEAM provides involve guarantees around memory, something that Rust can provide in its own idiomatic way. (Except maybe the hot code reload).