<div dir="ltr">On Wed, Sep 13, 2017 at 1:20 PM Roman Galeev <<a href="mailto:jamhedd@gmail.com">jamhedd@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> Personally, I'd just throw some more time after concurrent OCaml, and then write a translator from Erlang to OCaml :P<br><div><br></div></div><div dir="ltr"><div>Do you think concurrent OCaml has advantages over Erlang? And if yes, what are they, in your opinion?</div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">You are making tradeoffs whenever you choose another language.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* Semantically, OCaml is far superior to Erlang in any conceivable way.</div><div class="gmail_quote">* OCaml has a powerful type system, which Erlang doesn't.</div><div class="gmail_quote">* The native code generator in OCaml easily surpasses the bytecode interpreter in Erlang.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On the other hand:</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div><div class="gmail_quote">* 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).</div><div class="gmail_quote">* OCaml is unlikely to ever support hot code upgrade.</div><div class="gmail_quote">* OCaml currently has no dTrace-style production ad-hoc tracing facilities where Erlang has it naturally.</div><div class="gmail_quote">* OCaml programs are easy to make robust (cope with unknown input), but harder to make resilient (coping gracefully with internal failure).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">[0] Haskell is another excellent candidate here.<br></div></div>