[erlang-questions] languages in use? [was: Time for OTP to be Renamed?]

Loïc Hoguin essen@REDACTED
Sat Feb 15 14:06:29 CET 2014


I do not think you are fully informed about Erlang.

On 02/15/2014 01:01 PM, Pieter Hintjens wrote:
> A technology either lives, by growing and merging with others, or it
> dies. Erlang is far from being a living technology and survives pretty
> much thanks to a single dominant customer and investor. It claims to
> be the best solution for distributed systems, yet is entirely
> homogeneous, which is also an insane contradiction. Distributed
> systems by definition must span space and time, or they are
> LegacyAsAService.

Erlang comes with C-nodes and Java-nodes, you can plug pretty much 
anything you want in the cluster. At a previous client we have at some 
point used this to make PHP communicate with Erlang for example.

And of course you also have a couple dozen more ways to tie any program 
with a node if you can't make them into nodes directly. It's really very 
easy to make anything talk to Erlang.

> Erlang needs to shed its telco ties, and get an independent steering
> committee

Welcome to last year. Work in progress.

Erlang doesn't really need to shed its telco ties though. Today Erlang 
is heavily used in databases and HTTP related products, which happen to 
have the same requirements as telco products. So what it actually needs 
is to be tied with telco, DB and HTTP related companies, which is pretty 
much what they are currently doing.

> and create standards

I don't see that relevant. It's just one way to do things. You cited 
PHP, yet PHP has no standards, it's just an accumulated pile of code.

> and multiple implementations

Again not seeing that relevant. But in case it is, Erlang has of course 
the normal BEAM VM, but also HiPE, ErLLVM, LING VM and probably others I 
don't know about. They range from partial implementations running in the 
BEAM VM to completely independent implementations.

> also reach out to other language communities through distribution
> protocols like ZMTP

You mean like RabbitMQ?

> and educate those communities, while also
> exploiting them and merging with them.

I don't really see that happening in other languages either. At least 
not more than Erlang; Erlang people already talk about Erlang at 
conferences or user groups meant for other languages.

> Mock Java all you like. It's a hateful language in many ways. But Java
> programmers know how to work together. There are 6+ different Erlang
> stacks for ZeroMQ, all one-man projects, all lacking any community.

Have you considered that perhaps there isn't that much interest in 
ZeroMQ in the Erlang community? It sounds to me that there are just 6 
users and that their stack is just meant to fit their needs. Personally 
I wasn't aware of ZeroMQ's existence until about a year ago, and only 
because we randomly stumbled on you and Garrett in a bar in London.

There *is* a culture in the Erlang community that often prevents one 
stack from being the definite solution, though. People often just hack 
something in two days, put it on github and then forget about it. 
Sometimes it's a fork of an old project, sometimes a new one. This is 
also the reason there is no canonical package index.

Projects that do not suffer from this are very rare, notable exceptions 
being databases, HTTP and JSON. And by databases I mean actual 
databases, not drivers. Drivers are a mess of "works for me" forks.

I think this happens in part because there isn't enough Erlang 
developers. When you are a team of 3 building a service for millions of 
users, you tend to focus on making it work.

And that's okay, really. Perhaps Erlang doesn't have many programmers, 
but they still manage to handle an impressively high amount of traffic 
worldwide. The traffic/programmers ratio for Erlang is one of the 
highest there is. Hundreds of millions of people, if not billions, use 
products or services that run Erlang everyday, and that number keeps 
increasing rapidly despite the seemingly slow adoption.

Erlang *is* changing for the better. The problem is how the average 
programmer sees Erlang. No amount of decisions can change this 
overnight. It's easy to fix a product; it's not easy to fix its image.

-- 
Loïc Hoguin
http://ninenines.eu



More information about the erlang-questions mailing list