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.