<div dir="ltr">Let me add that distribution means one of two things: LAN distribution or WAN distribution. In the former case, the network can be considered ample bandwidth, low latency, only with mild duplication, packet loss, reordering characteristics and so on. On the other hand, the WAN situation is almost the opposite of that, except perhaps for the bandwidth part.<div>

<br></div><div>Erlang solved the distribution for the LAN part pretty well, but the WAN part is vastly different. Yet I think that the Erlang tools are among the best for handling distribution. And I must say I, on a daily basis, can point to newly written code and go "Yes, that was solved, 15 years ago in Erlang... better".</div>

<div><br></div><div>Erlangs unique status is not "we understand distributed systems" insofar as the other major points in Bjarne Deckers thesis[0]. It is the conglomerate of every decision which makes a language. This is also why a language like Go is awesome, but gives you programs written in a much different style than in Erlang.</div>

<div><br></div><div>The problem with 6 different implementations of ZMQ mostly stems from a number of typical social problems in Erlang:</div><div><br></div><div>* One developer is enough, so you will write the full system yourself. This is also the problem for Haskell, Clojure, Common Lisp, etc, but not Java, C#, ...</div>

<div>* No separation of the protocol from the concurrency mechanisms in the code base. This means you can't plug-in other concurrency models with different guarantees, and so you are forced to reinvent the wheel. A really good example is the new pure-erlang-zmq implementation. But also the Erlang emysql driver has the same problem. Thus the different implementations are equal in the protocol handling parts, but they differ in how they handle concurrency on top.</div>

<div>* We don't want a NIF. We do want a NIF. jiffy is a much faster JSON library than jsx, but jsx is written in pure Erlang. If you are going for speed, then surely jiffy is the best. If you are going for low-latency operation and proper preemption, then jsx wins.</div>

<div><br></div><div><br></div><div>[0] rambled on this a couple of years ago. The links are 1 hop away from this <a href="http://jlouisramblings.blogspot.be/2012/10/ramblings-on-thesis-of-bjarne-dacker.html">http://jlouisramblings.blogspot.be/2012/10/ramblings-on-thesis-of-bjarne-dacker.html</a></div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 16, 2014 at 9:43 AM, Pieter Hintjens <span dir="ltr"><<a href="mailto:ph@imatix.com" target="_blank">ph@imatix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog <<a href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>> wrote:<br>
<br>
> Erlang provides a stable<br>
> distributed system development platform that provides many avenues for<br>
> integration, as shown by its successes, so your complaints show your<br>
> ignorance.<br>
<br>
</div>Good job on smacking down my ignorant complaints. I feel chastised and<br>
would slink back to silent observation of Erlang's slow demise at the<br>
hands of people who always know better. Except, I will take the bait.<br>
<br>
Cloudi looks valiant in a tragic fashion. A 1-person project still in<br>
beta that uses REST as its messaging carrier. How can I count the ways<br>
this will fail? Anyone looking for a HTTP-based cloud will use Open<br>
Stack, period. Anyone smart will be thinking of new designs based on<br>
much cheaper distributed messaging. People broadly either embrace risk<br>
(then won't use this), or hate risk (then won't use this).<br>
<br>
Erlang's unique status used to be, we understand distributed systems.<br>
Today that's changed. There are many other ways to make distributed<br>
systems, more cheaply, more successfully.<br>
<br>
Erlang either gets its cost model way down, or it dies. Quote me on<br>
that if you like. Our industry has no pity for excess friction, and<br>
you have competitors.<br>
<br>
I think this thread is really important. And the questions should not<br>
be "what is Erlang called", since that's trivial to solve (just stop<br>
saying "OTP" in polite company). The question should be, "where are<br>
there friction costs and how can we remove them?"<br>
<br>
My example of outreach to other languages is about friction costs. If<br>
it's trivial to integrate polyglot languages with Erlang, friction<br>
costs fall right away.<br>
<br>
Smacking down the ignorant won't remove friction costs.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Pieter<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>J.
</div>