[erlang-questions] Erlang VM in Rust

Zachary Kessin <>
Thu Sep 14 08:15:34 CEST 2017


It seems to me an Idea that is interesting in theory but would involve a
*LOT* of work for an unclear benefit.

Zach
ᐧ

On Thu, Sep 14, 2017 at 1:54 AM, Tristan Sloughter <> wrote:

> Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca) and
> improvements to BEAM :)
>
> --
>   Tristan Sloughter
>   "I am not a crackpot" - Abe Simpson
>   
>
>
> On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
>
> On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <> 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.
> *_______________________________________________*
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Zach Kessin
Teaching Web Developers to test code to find more bugs in less time
Skype: zachkessin
+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170914/62f80eb4/attachment.html>


More information about the erlang-questions mailing list