[erlang-questions] Erlang VM in Rust

[Roman Galeev]

 > don't underestimate how productive Erlang

I don't. In Erlang, I can make a system to work relatively quickly, and
with all these features like resilience and concurrency, even with some
distribution, and I like it. On the other hand, a powerful type system can
ease life a lot too. Kind of a tradeoff you've mentioned I guess. Anyway,
thank you for the detailed response.

On Wed, Sep 13, 2017 at 1:43 PM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> 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.
>



-- 
With best regards,
     Roman Galeev,
     +420 702 817 968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170913/65362ab0/attachment.htm>