[erlang-questions] Erlang VM in Rust

[Jesper Louis Andersen]

On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <jamhedd@REDACTED> wrote:

> > Personally, I'd just throw some more time after concurrent OCaml, and
> then write a translator from Erlang to OCaml :P
>
> Do you think concurrent OCaml has advantages over Erlang? And if yes, what
> are they, in your opinion?
>

You are making tradeoffs whenever you choose another language.

* Semantically, OCaml is far superior to Erlang in any conceivable way.
* OCaml has a powerful type system, which Erlang doesn't.
* The native code generator in OCaml easily surpasses the bytecode
interpreter in Erlang.

On the other hand:

* OCaml is currently not parallel in any way. There has been a long effort
in fixing this, but even *if* it gets released, we are looking at years of
maturing needed before we can hope for robust operation.
* OCaml currently uses something like Lwt and/or Async for concurrent work.
This is Node.js in disguise. I don't believe in indirect concurrency
codings in general, far preferring Erlang or Go's direct approaches (in
which you favor preemption over cooperation in multitasking).
* OCaml is unlikely to ever support hot code upgrade.
* OCaml currently has no dTrace-style production ad-hoc tracing facilities
where Erlang has it naturally.
* OCaml programs are easy to make robust (cope with unknown input), but
harder to make resilient (coping gracefully with internal failure).

So proviso OCaml gets a good parallel story, and we can implement the
important parts of Erlang on top of that, then I think there are programs
which can be written in OCaml with advantage. In particular those which can
afford to be restarted once in a while. This is true for many modern
systems in which you are deploy clusters of nodes() and provisioning them
this way. The prime candidate programs are those which require the
efficiency the OCaml native code compiler provides and where you can't just
run the OCaml program behind an Erlang Port easily.

The *current* state of the art: use OCaml whenever you have a problem
requiring the combination of functional abstraction and efficiency[0]. If
you don't require the abstraction levels OCaml provide, go for C, C++,
Rust, Go, etc. But chances are that the added productivity of OCaml will
get you a far better and faster program when you are working with a limited
time frame, since you can try more solutions, quicker.

If your problem doesn't require efficient use of the CPU core, don't
underestimate how productive Erlang is. Since everything are just Erlang
terms, you can often write a good program in a fraction of the time it
requires to come up with a good type model in something like OCaml. All
tooling supports Erlang terms. This is a powerful abstraction which can be
put to good use. And you get resilience on top. I should really blog about
how unfairly effective Erlang is at being productive. Efficiency is far
from the only important factor in software development.


[0] Haskell is another excellent candidate here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170913/7b9b1fed/attachment.htm>