
Enigma: Erlang VM Implementation in Rust - adamnemecek
https://github.com/archseer/enigma
======
archseer
Thanks for sharing, author here! (AMA?)

I had a lot of fun working on this project, having implemented enough of the
VM to run both Elixir and IEx before I stopped.

Ultimately development stalled since I couldn't get any community interest (I
was hoping to give an ElixirConf talk but wasn't accepted either). Was hoping
to raise some interest and find some contributors in similar vein to
[https://github.com/RustPython/RustPython](https://github.com/RustPython/RustPython)

Nowadays I write a lot less Elixir and a lot more Rust.

~~~
hopia
A new Erlang VM with just replicated functionality is a fairly hard sell to
the Erlang/Elixir community, who brag with the industrial track record of the
BEAM.

I believe you'd get much more interest if there was some ambitious new promise
for this new VM, such as 10x sequential performance etc.

~~~
fortran77
We do a lot of Erlang work here. The BEAM is so reliable that I wouldn't spend
1 minute looking at an experimental alternative.

~~~
spockz
Can you share something on this reliability? Is it more reliable than the JVM?
Or is it more predictable in terms of performance? I’ve found the jvm itself
to be rock solid as well.

~~~
hopia
Erlang VM is consistent/predictable in terms of latency, it's engineered that
way. For pure computational performance you won't find it optimal.

------
mwcampbell
A similar project is Lumen [1], which is targeted primarily at WebAssembly.

[1]: [https://github.com/lumen/lumen](https://github.com/lumen/lumen)

~~~
archseer
Yep! They appeared shortly after I started and were backed by Dockyard. I
think they didn't have much success finding external contributors either
though :/

~~~
bcardarella
The project is still under heavy development to get to a point where external
contributors make sense. We hope to be there soon!

~~~
archseer
Best of luck!

------
lelf
Another one from a different author (with slightly different goals):
[https://github.com/kvakvs/ErlangRT](https://github.com/kvakvs/ErlangRT)

~~~
archseer
Also check out kvakvs' BEAM Wisdoms site: [http://beam-
wisdoms.clau.se/en/latest/](http://beam-wisdoms.clau.se/en/latest/)

It was a big help initially to grok the bytecode format.

------
chx
> sans the distributed bits for now

I thought the very point of Erlang was the distributed nature of BEAM? Failure
is normal etc?

~~~
archseer
I wanted to tackle distribution eventually, but it was also by far the most
complex part of the implementation.

------
JimmyRuska
I would love an erlang implementation where there can be many versions of the
code in memory, where you could re-order the message pattern matching at
runtime, where you can specify arguments to functions in terms of a map,
specify the args and the types of that map specification, and have it compile
into numbered argument, that way you don't have to add update many many
functions to add another argument.

~~~
toast0
> many versions of the code in memory,

You can model that today if you script compilation/loading. When loading a
module, you could first load it as {?MODULE, ?VERSION} or ?MODULE_?VERSION if
we can't stuff a tuple there, and then also load it as ?MODULE, to use when
you don't specify a version.

The hard part is deciding what version to call when, and passing that through
to the call sites. And also, to figure out how to signal a process that you
want it to update its version.

> where you could re-order the message pattern matching at runtime,

Pattern matching order is part of your code, and hot loading is the way to
make changes to your code.

> where you can specify arguments to functions in terms of a map, specify the
> args and the types of that map specification, and have it compile into
> numbered argument, that way you don't have to add update many many functions
> to add another argument

You could do this yourself today as well; a function could check if its
argument is a Map and demapify the arguments, or you could make a utility
call_function(Module, Function, Arity, Map) that demapifies and calls
erlang:apply on the function. Or, you could have your rapidly changing
functions all just take Maps; I did that in the past with Proplists.

~~~
JimmyRuska
Thanks for these suggestions!

Shouldn't there be a way for the compiler to know enough to convert the map to
positional arguments, so long as the map params could be put into a spec?
Something like that would be super nice, because I think tail calls in Erlang
cost nothing so long as you keep the same arg positions. Having a map is
always a convenient way of starting a function and evolving it, but having it
with a few more constraints and with equal performance would be better. If I'm
not mistaken I remember dart made a similar optimization.

~~~
toast0
If the functions are exported, the compiler wouldn't be able to optimize
calls. Dynamic modules and hotloading means there's no expectation that what
you had when compiling is what you're running against in production.

If they're in the same compilation unit, the newer SSA based optimizer might
do some cool stuff for you; it's always interesting to look at the optimized
code that comes out of compiling/loading.

In general though, I would tend not to worry about efficiency of passing a map
instead of traditional arguments. Most likely there's other, bigger, things to
worry about; usually finding the right communications patterns and algorithms
makes a bigger difference.

------
battery_cowboy
I love it; I don't think everything has to be useful to be worthwhile.

------
amelius
What are some good books on the topic of VM implementation? If no books, then
papers also welcome.

(Not necessarily related to Erlang)

~~~
enitihas
Crafting Interpreters is a good book, free to read online. For papers you can
read "The implementation of Lua 5"

------
throwaway894345
This is cool, but looks like development has stalled. Last commit was Sept
2019.

