I'm not super familiar with any of those, but looking at BEAM at the cursory level, it has very little to do with "distribed-ness". It's a VM implementation with heavy focus on concurrency, which is only a small part of distributed systems and arguably not even in the same area of research.

You can make anything that is network-enabled a part of a distributed system, assuming you can express protocols within that 'thing'. If the VM supports bitwise operations, for example, you could support binary protocols to interface with anything else. The "VM" part of it, by itself, has very little impact on the entirety of the distributed system.

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).