Bastion – Highly-available distributed fault-tolerant runtime

So trying to reach for strong static typing and zero-copy message passing are natural next steps -- and if that's not possible with Elixir itself, we'll search for it in other languages.

At least that's the case for me.

Yeah; I always added type annotations to my code and ran Dialyzer...I wish there was a stricter compilation mode for that. That said, I really liked the 'optimistic' part of it, so I didn't spend a large amount of time correcting my type specs when proper testing proved it work.

I can agree with bfrog's comment too; Rust's typing can definitely help eliminate a bunch of classes of bugs...but honestly I'm not sure I ever ran into them using Erlang in production anyway. Immutable data + message passing tends to make it easy to implement things correctly, whereas some of Rust's more standout features seem designed to solve problems caused by the language itself picking a different set of tradeoffs (i.e., borrow checking as part of what is necessary to manage memory without risking it going out of scope prematurely, or being unable to be reclaimed at a deterministic time by the compiler). I'm not familiar enough with Rust myself to really comment though; I just know that in two and a half years of production Erlang, the only bug we ever encountered was caused by a C driver (and our own bad design in not circuit breaking calls to it, leading to restarts that trickled up the supervisor chain under heavier load than we'd tested for. None of which would Rust have been able to help us with. In fact, even the driver, the issue was an unnecessary network call that sometimes hit an empty cache, causing a huge network hiccup that led to an unhandled timeout). It got 'correctness' as well as 'fault tolerance'. At least as much as a language can (i.e., we could still implement the wrong things, such as when we implemented an O(N^2), but correct, algorithm, that we had to fix to an O(N) when we noticed certain calls being too slow)

For other types, it's not possible without either adopting Rust's memory model (but that's a huge set of tradeoffs to take on; completely change the language), or giving up the GC benefits of everything being process(stack) allocated, which would entail a whole new set of tradeoffs (and probably not be much faster).

I, personally, don't see that direction as a plus, as such.

Not sure about your third/fourth point; that's Erlang's behavior, no? One actor being busy won't starve others, for CPU or IO. It's pre-emptive; the VM counts reductions and moves on (and not really sure why, given that, you'd want user controlled pre-emption; I never had an issue with one actor starving others, unless calling out to some C code or something, and even that is mitigated with dirty schedulers). Detecting infinite loops could be optimistic, like Dialyzer's typing, I think, but could never be 100% because, yeah, halting problem.

And as above, totally agree on typing, though I personally like Dialyzer's optimistic approach (I just wish type specs were enforced).

But, per the original, I am totally on board with more languages supporting actors...I just was curious what 'a better Erlang' would look like. Some of your bullets seem "a better language (for my use case)", and not really aligned with Erlang's goals.