ErlangRT - New Erlang VM in Rust

Wow another Erlang VM made with Rust! Other one is here GitHub - archseer/enigma: An Erlang VM implementation in Rust · GitHub

Feels like this is a problem:.

A process is simply a long running future, scheduled on top of tokio-threadpool work-stealing queue

A process should be exactly what it is in the normal BEAM, otherwise you’re gonna run into problems.

Yeah I see more future for ErlangRT because Enigma VM does shortcuts like that.

This is describing how this VM implements a process, it isn’t saying that the process will be something different from the perspective of an erlang programmer.

Tokia does IO based scheduling AFAIK, so the machine will probably behave differently under CPU bound load than the original BEAM.

Programmers on the BEAM usually rely on the fact, that regardless the load of the system, they will eventuelly get some time slot to do their thing.

So, I’m not disagreeing that the new VM may perform differently than the current one. I’m simply making the sort of ontological point that a Future is not fundamentally a different kind of thing than an erlang process as viewed from the VM. A process in the BEAM is a struct with various properties that runs on a threaded work stealing scheduler. That’s exactly what a Future is too.

Well, but the underlying schedulers work differently. While the BEAM is pre-emptive, Tokios futures are not.

Of course, from a (erlang/elixir/whatever) programmer things won’t change. They just spawn their way through, but programms will behave differently under load.

Of course there might be interest for the changed behaviour, or perhaps its the price some people are willing to pay for other benefits of this re-implementation, but currently I have not yet seen any benefits…

I think it’s just like @NobbZ said and you’ll lose one of the biggest benefits of BEAM. Preemptive scheduling was the biggest reason I got interested in Elixir to create web apps..

Elixir / Erlang is preemptive, but the C code that runs a process’s BEAM byte code is not pre-emptive. Languages built on this byte code are effectively preemptive because the underlying C can choose to yield at frequently occurring points in that byte code. Presumably the Rust code inside the Future could work the same way.

It’s entirely possible that I missed something here and their plan is to have each future churn on bytecode till the bytecode does IO, but there’s nothing about a future that requires that that’s the case any more than the fact that the BEAM is written in C.

I actually think that the new BEAM implementations should look into exploring other design trade-offs - other memory management schemes, different kinds of schedulers, different data representation, interpreters vs compilers, etc. We already have BEAM working like BEAM, so I don’t see much value in just replicating that exactly, on the other hand exploring new ideas might bring back some valuable insight into the main implementation.