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.

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.

As with any improvement or substantial change, one first must have a prototype, a baseline to discuss. It is already hard to just repeat existing BEAM with a good degree of similarity, and I believe it is prohibitively hard to change something WHILE reimplementing BEAM. So all things come in their time. Rust makes this refactoring step simple and reliable.

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.

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…