[erlang-questions] languages in use? [was: Time for OTP to be Renamed?]
Jesper Louis Andersen
Sun Feb 16 12:48:39 CET 2014
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.
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
Erlangs unique status is not "we understand distributed systems" insofar as
the other major points in Bjarne Deckers thesis. 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.
The problem with 6 different implementations of ZMQ mostly stems from a
number of typical social problems in Erlang:
* 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,
* 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.
* 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.
 rambled on this a couple of years ago. The links are 1 hop away from
On Sun, Feb 16, 2014 at 9:43 AM, Pieter Hintjens <> wrote:
> On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog <> wrote:
> > Erlang provides a stable
> > distributed system development platform that provides many avenues for
> > integration, as shown by its successes, so your complaints show your
> > ignorance.
> Good job on smacking down my ignorant complaints. I feel chastised and
> would slink back to silent observation of Erlang's slow demise at the
> hands of people who always know better. Except, I will take the bait.
> Cloudi looks valiant in a tragic fashion. A 1-person project still in
> beta that uses REST as its messaging carrier. How can I count the ways
> this will fail? Anyone looking for a HTTP-based cloud will use Open
> Stack, period. Anyone smart will be thinking of new designs based on
> much cheaper distributed messaging. People broadly either embrace risk
> (then won't use this), or hate risk (then won't use this).
> Erlang's unique status used to be, we understand distributed systems.
> Today that's changed. There are many other ways to make distributed
> systems, more cheaply, more successfully.
> Erlang either gets its cost model way down, or it dies. Quote me on
> that if you like. Our industry has no pity for excess friction, and
> you have competitors.
> I think this thread is really important. And the questions should not
> be "what is Erlang called", since that's trivial to solve (just stop
> saying "OTP" in polite company). The question should be, "where are
> there friction costs and how can we remove them?"
> My example of outreach to other languages is about friction costs. If
> it's trivial to integrate polyglot languages with Erlang, friction
> costs fall right away.
> Smacking down the ignorant won't remove friction costs.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions