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

[Joe Armstrong]

On Sat, Feb 15, 2014 at 1:01 PM, Pieter Hintjens <ph@REDACTED> wrote:

> On Fri, Feb 14, 2014 at 4:39 PM, Miles Fidelman
> <mfidelman@REDACTED> wrote:
>
> > Actually, the demand for both Cobol and analog engineers is UP.
>
> Friend of mine was just laid off from a 15-year Cobol job. One can't
> make general conclusions from small samples.
>
> The argument that keeping technology elitist creates wealth is insane
> and should be laid to rest rapidly. Who here is building new
> businesses on LU6.2? Right.
>
> It was extremely enlightening last week, at a workshop with a medium
> sized Erlang shop. Opening statement: "We chose Erlang because it lets
> us build large distributed systems with a small team." Then two full
> days of, "oh, that's one more serious problem we're facing, caused by
> how Erlang does things."
>

Could you be more explicit? What is that Erlang does that causes problems?
It seems crazy that there are two days of discussion about this and the
core Erlang group gets to hear nothing about this.

I'm really keen to hear about problems users have, bit I'm not psychic. I
can't read minds
somebody has to tell us what the problems are. If you don't tell us about
the problems
we can't fix them.


>
> A technology either lives, by growing and merging with others, or it
> dies.


Technologies don't die once they get to a critical mass. They live forever.
Cobol never died. It just stoped expanding. This happens when the cost of
converting legacy
code exceeds cost of developing new code.

Erlang is far from being a living technology and survives pretty
> much thanks to a single dominant customer and investor.


It was actually banned by it's "single dominant customer" but survived
anyway :-)

What would happen if the single dominant customer lost interest is a matter
of pure speculation.
Things would happen :-)



> It claims to
> be the best solution for distributed systems,


Where?



> yet is entirely
> homogeneous,


Yes



> which is also an insane contradiction.


No


> Distributed
> systems by definition must span space and time, or they are
> LegacyAsAService.
>


Ummm - problem is we haven't a clue how to do this.


>
> Erlang's elitism and lack of broad appeal is the #1 threat to its long
> term survival. It is frankly the Algol 68 of the telco industry.
> Awesome language!! Yay!!!
>

I don't understand the elitism jibe. I (and others) believe Erlang to be
better at solving a particular class of problems that some other languages.
If we say so, is this what you call elitism? or should we keep quiet?

Erlang is really really bad at solving a boatload of problems, and we also
say this.
"Lack of broad appeal" is understandable. I guess " building apps for
android"
has "broad appeal" or "desktop applications" has board appeal.

Making servers that "never stop" is never going to have broad appeal.
The only thing we could ask for is "broad appeal in a niche" where the
 niche
is "building non-stop servers". This is a bayesian concept - broad appeal
 "subject to the condition that you are building faulty tolerant servers"
and in this
niche I think we are well thought of.

Many niche language do not have broad appeal - but are totally dominant in
their niche.
For example, postscript for printers :-)



> To measure market success in terms of "how much can a developer earn"
>
    is also so foolish I'm embarrassed to read such views.

I agree

This is meant

> to be a list of clever people. For pity's sake. That's like claiming a
> protocol is valuable because it's so hard to implement.


But I never ever heard anybody claim that a protocol was valuable because
it was
difficult to implement.

One the contrary, encodings like JSON are claimed to be valuable for
exactly the
opposite reason that they are easy to implement.



> Wealth comes
> from building up. How can you build up if your basic layers aren't a
> commodity? There's a million times more wealth built on PHP than
> Erlang. Real wealth.
>




>
> Erlang needs to shed its telco ties, and get an independent steering
> committee, and create standards, and multiple implementations, and
> also reach out to other language communities through distribution
> protocols like ZMTP, and educate those communities, while also
> exploiting them and merging with them. Living systems are like the
> Borg; they grow by merger.



> Mock Java all you like. It's a hateful language in many ways.


Who mocks Java? We say "for this class of programs we believe Erlang to
better than Java
and here is our evidence"

Java is great for what it was designed to be good at (as is Erlang) -
My  smart card for public transport is a Java VM powered by induction
currents,
it's a miracle of technology, I'm not mocking this.



> But Java
> programmers know how to work together.


Do they? What's the evidence for this? When I meet Java programmers all
they seem to do is argue about
which framework to use. People in general find it difficult to work with
each other. I can't think
of any reason why Erlang programmers would be less good at working together
that X programmers
(where X is any language you care to name).

The ability to work with other people must be a property of the people
involved and not the technology they work with,



> There are 6+ different Erlang
> stacks for ZeroMQ, all one-man projects, all lacking any community.
>

This is avery interesting comment. Why are there 6 stacks and not one?
Possible reasons:

1) The 6 different developers didn't know about each other
2) They knew about each other but their stacks have different
non-functional requirements
3) They wrote the stack for their own personal enlightenment and had no
interest in
it being widely used
4) Nobody uses the code

That they lack community might mean that erlang programmers feel no
pressing need to
communicate with applications in other languages.

When code starts getting widely used, new users start asking questions like
"they are 6 stacks" which is best? - and then a shake-down occurs. This has
happened previous with HTTP stacks - there used to be
several - but they seem to have converged on one now.

The fact there are 6 ZeroMQ stacks means this is "early days" and that this
convergence on the
best stack has not yet happened.

I'm speculating here: At a guess  5% of all programmers are writing
distributed applications. Of these
10% are writing cross-language applications. Most will use REST protocols.
The number of people
who want to connect Erlang to X via AeroMQ must be rather small and so we
don't see any pressure to
consolidate the libraries.

Me, I'm interested in Connecting Erlang to Julia via ZeroMQ, but the real
underlying problem has
nothing to do with the plumbing problems, ie I'm not that excited about
whether it's ZeroMQ of TCP
but rather the *semantics* of the interface. In the Julia world there are
things called arrays (of 64 bit signed integers) and int the Erlang world
there are tuples and lists of big integers. So when we talk
to each other we need to do some conversions, and it's very unclear how.

ZeroMQ (or Erlang) or sockets, or UDP solves part of the problem, but what
about the rest.
Do we add an XML layer, or JSON, or ASN.1 or thrift. In the erlang world
(and smalltalk) integers
are integers - but in C they are (signed|unsigned, 8|1632|64) integers and
life gets tricky.

Another reflection: 6 implementations rather than one means 6 chances to
get it right. It means diversity.
It's kind of nice to go into a bar and find 6 different beers, rather than
one, but it is confusing to
a newcomer, and a stranger who walks into the bar and does not know what to
order.


This mail reply got long - it was triggered by Pieters comment about 6+
different implementations
of ZeroMQ. I keep pondering this - it raises and interesting question.

I am very guilty of not collaborating with other people and
making my own implementations and I don't know if its a strength or a
failing.
The main reason I implement stuff myself is to learn how things work
through my own personal experience, not though a lack of a desire to
collaborate. I just don't really understand how things work if I haven't
implemented them myself.

Cheers

/Joe






>
> -Pieter
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140216/b9d5f24e/attachment.htm>