1. 21
  1.  

  2. 10

    Having worked on an Erlang virtual machine, I have to say that the gap between meaning of system calls and the Erlang code is quite huge.

    Erlang is a (distributed) environment with a quite simple language on top of it. Erlang environment is complicated and reminds a Lisp environment or an operating system more than a simple virtual machine: it includes erl_eval, everything needed for running/supervising actors, transparent network connections and connecting to different local/remote shells. Even its standard library is structured as an “application” (stdlib) and the basic operation of a virtual machine is also controlled by another “application”, kernel. It even has a boot process controlled by “boot scripts” (serialized dumps of Erlang structures that declaratively describe boot process).

    Erlang is more of a distributed hosted OS-like environment than a virtual machine like JVM.

    1. 7

      To parrot Joe Armstrong, Erlang is meant to run forever, so running some code then quit is not a pattern typically suited for Erlang. I wrote a small lib to reduce overhead for such use-cases of running code, then quit:

      http://blog.ikura.co/posts/notp-a-middle-way.html

      The overhead is real when using Erlang as is. Would you pack your bags light if you were set off on a multi-year journey? I for one would pack quite a bit in my bags.

      1. 1

        Fascinating. I’d have guessed it would use as few syscalls as possible to reduce call overhead and maybe increase determinism by keeping most activity in the VM itself. Could be optimization potential here.

        1. 4

          Call overhead in Erlang is really big. Erlang needs to do the dispacthing as late as possible to be able so that the developer can change the running code. On the other hand, this is a really strange use case for Erlang. It is not strange to have Erlang servers running for months/years. So it makes a lot of sense to optimize that use case: you start by default a thread per core and you have to launch schedulers to schedule erlang processes. It doesn’t make any sense to optimize for the use case where you create a vm to print something and then you shut it down.