[erlang-questions] Erlang VM in Rust
Sat Sep 16 12:03:40 CEST 2017
Reimplementing Erlang in Rust would be a huge task if you want 100%
Erlang is several things
1) A programming language
2) A huge set of libraries
3) A large set of tools
The language can be implemented as a byte code emulator (or threaded
+ a load of BIFs (or NIFs)
The emulator bit is easy (apart from the GC and process management) -
the problem is
all the BIFs and NIFs that are not written in Erlang but written in C.
If I was going to re-implement Erlang I'd try to define a subset of
Erlang with which the
entire emulator GC and process management code could be written.
This subset would be such that it could be cross-compiled to C (or
Rust, or anything)
The goal would be to write MORE in Erlang not less - unfortunately the
trend of the
last few years has been to write LESS in Erlang and more in C (ie with
NIFS) - this improves
performance but makes reimplementation far more difficult.
The path we took in the early 1990's was to make erlang more
performant at the expense of portability. So we moved from a byte
coded machine (JAM) to a threaded word interpretor
(BEAM) - the machine got bigger not smaller.
What we never tried was moving in the opposite direction of making the
and more portable - I'm thinking an ANSI C interpreter and huffman
In the 1990's this would have been far slower than the JAM - but today
we're talking GHz
whereas it was MHz in the 1990's.
It would be great tor re-engineer Erlang, and to take the opportunity
to make it more
portable and smaller.
If we had in mind the goals "very small", "very portable", "as much as
possible in erlang, as little as is necessary in C/rust" we might end
up with a nice machine.
I think the gains would come from a careful re-design of the VM not
changing the machine in which the VM is implemented. I believe the Lua
VM has 37 instructions and a small emulator.
The trick is having a VM with correct instructions for implementing Erlang .
The JVM and .NET have the wrong instructions - the JAM and BEAM have
(or had) single
instructions for spawning processes and sending messages - I guess
these could be
augmented with Opcodes for micro GCs and process management.
I'm not convinced that a better programming language to implement the VM helps -
the tricky bit is getting the VM machine instructions correct - at
this level of abstration
the VM is just moving memory around comparing things and jumping
around - which is pretty
easy inn *any* programming language.
In my opinion the great progenitor of VMs was the Pascal P-code
machine (from which
.NET and JVM derive) - then came the WAM (for Prolog) then we added opcodes for
process spawning and message passing (JAM) and turned this into
threaded code (BEAM) .
What would be an interesting experiment would be re-engineer the VM
turning all the
things essential to Erlang and Elixir into opcodes and make an
emulator for this.
The emulator should (or course) we written in a dialect of Erlang and
cross-compiled to C
Note: This is how we didn't implement Erlang. I designed and
implemented the original VM and opcodes in Prolog - then Mike William
re-implemented the Prolog emulator in C.
The mistake here was that Prolog has built-in GC and C does not - so
there were no
instructions in the JAM for GC (just an instruction so say when the
stack and heap were in
a safe state for GC to occur)
By all means re-implement Erlang - but make it smaller and more
portable, and forget the NIFs
On Fri, Sep 15, 2017 at 9:20 PM, Heinz N. Gies <> wrote:
> True macOS and Windows are both tier 1 platforms for rust (along with linux as 3 rd option). I don’t think it’s very relevant however, as you said yourself neither are server oriented systems (windows might a bit be). But for the majority of users it’d effectively be ‘linux or good luck’ unless they plan to deploy on a macbook.
>> On 15. Sep 2017, at 20:01, Sergej Jurečko <> wrote:
>>> On 15 Sep 2017, at 19:47, Heinz N. Gies <> wrote:
>>> The answer would have to be “a bit” it’s on and off depending on packages available and versions, same goes for BSD sadly.
>>> While rust does make an real effort to run outside of linux it’s very much “linux or good luck to you my frinbed” these days …
>> Linux or good luck is far from true. Rust works just fine and is well supported on Windows, macOS, iOS and Android. All giant platforms, though user not server oriented. Obviously a consequence of the largest Rust user being Mozilla.
> erlang-questions mailing list
More information about the erlang-questions