[erlang-questions] languages in use? [was: Time for OTP to be Renamed?]
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
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
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.
More information about the erlang-questions