[erlang-questions] Erlang VM in Rust

[Tristan Sloughter]

Alternatively, work on Alpaca (https://github.com/alpaca-lang/alpaca)
and improvements to BEAM :)
--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson
  t@REDACTED


On Wed, Sep 13, 2017, at 04:43 AM, Jesper Louis Andersen wrote:
> 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.
> _________________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170913/598173bd/attachment.htm>