
A response to "Erlang - overhyped or underestimated" - cannedprimates
http://jlouisramblings.blogspot.com/2010/12/response-to-erlang-overhyped-or.html
======
nivertech
I used to all kinds of syntax or absence of it, like in Lisp or Forth. So I
have no problem with Erlang syntax itself, but with its verbosity and
inconsistency.

1\. Versbosity

Sorted by code verbosity level, Erlang is somewhere in between Java/C++/C#
(more verbose) and Ruby/Python (less verbose). But closer to dynamic
languages, since you don't need to specify the types.

OTP code is significantly more verbose than plain Erlang and adds some
boilerplate code (which can be generated for you by tools, like emacs or
rebar, but you still need to read it and maintain it).

When you adding dialyzer specs, code become even more verbose. Since you need
to duplicate function and argument names in the specs. Even worse - you need
to duplicate dialyzer specs in edoc specs, since edoc uses it's own specs.

You can write your own macros and parse-transforms to reduce verbosity, but
they aren't 1st class citizens and will not work from shell.

Given said all that, you still can expect up to 1:10 SLOCs reduction,
comparing to C++ or Java, for large real life distributed applications.

2\. Inconsistency

Example of inconsistency:

    
    
      proplists:get_value(Key,Proplist)
      dict:fetch(Key, Dict)
      dict:find(Key, Dict)
      gb_trees:get(Key, Tree)
      gb_trees:lookup(Key, Tree)
      ets:lookup(Tab, Key)
      dets:lookup(Tab, Key)
      element(Index,Tuple)
      lists:nth(Index,List)
      array:get(Index,Array)
        

All this can be written in modern languages as:

    
    
      Data[Key]
      Data[Index]

~~~
killedbydeath
How are you getting 1:10 LOC ratio over C++? My Python code would be at most 3
times more dense than C++. C++ has some very expressive high level constructs
(template tricks mostly), please do not put it into the same bin with Java.
And even Java gets less verbose with annotations.

~~~
nivertech
I'm talking about large applications.

In C++/Java large amount of code is defensive programming, locking and
synchronization - you don't need it in Erlang.

Distribution - even if you use CORBA/RMI you still have to write a lot of
plumbing code in C++/Java. In Erlang it's comes almost for free.

Binary protocols handling - very succinct in Erlang with binary syntax and
verbose in C++/Java.

~~~
killedbydeath
I am not too familiar with Erlang, but I am very familiar with Python and C++.
And you put Erlang between Python and C++ by verbosity, so I made my
conclusions accordingly. Also, synchronization and locking (with mutexes) are
not the only approach to parallelization in C++. You can immutable objects,
futures and other high level concepts. But Erlang has to be really nice for
the stuff it was designed for, I have no doubts about that.

------
swannodette
Excellent post.

As I broaden (and continue to deepen) my knowledge of programming languages -
Ruby, Python, Objective-C, C, C++, Java, JavaScript, Prolog, Scheme, Racket,
Common Lisp, Io, Haskell, Clojure, Smalltalk ...

... I've become very, _very_ , _VERY_ wary of programmers who are overly
concerned about syntax.

I've also become wary of programmers who care too much about regex and string
manipulation facilities.

This post does a great job of concretely explaining why I have misgivings
about people who express these kinds of opinions.

~~~
jlouis
Yes, the main point is that strings in many cases is the hammer in the
toolbox: it always works, even when you needed the saw or the screwdriver.

And many webservices can be manipulated from strings alone.

------
philwelch
_Remember this: “In OO-languages state is kept in objects; in Erlang, state is
kept in processes”._

If you think of OOP as "objects holding state and passing messages to each
other", it's not difficult to map that idea to the Erlang world.

~~~
seabee
i.e. OOP as originally envisaged, in the olden days of Smalltalk.

~~~
thesz
But with pattern matching, atoms and tuples and asynchronous and synchronous
send and receive.

A big departure, I should say.

------
gaiusparx
Strange to see there are people concerning about different syntax in different
languages. Kind of like expecting Chinese language to have the same grammar as
English.

------
ph0rque
As someone who has been learning Erlang for a few months now, I mostly agree
with the article. The only statement that rubbed me the wrong way was:

 _Many Erlang programs are running in companies with no open-source policy as
well - don’t expect the programmers of those systems to even be able to talk
about what they do. It is a competitive advantage to keep the mouth shut._

In fact, I see the shut mouths as a disadvantage in some cases: coming from
the Ruby/Rails world, it was a shock for me to not find an open-source
library, yet find a request for it back in 2000. Further investigation
revealed some well-known authors having worked with the closed-source version.
What we'll probably do is take the equivalent Ruby library, and make it work
through Erlectricity.

------
allertonm
I've no horse in this race, but the comment..

"I have written production level code in Erlang, namely a BitTorrent client
good enough for everyday use"

...seems to be going some way towards proving the Acharya's point #4 for the
following reasons:

1) No reference to any actual users of the code apart from the author himself.

2) No link to where the code is available.

3) Code is a single-user client, when Erlang's strength is usually considered
to be in multi-user servers.

It's not obvious that the author understands what is meant by "production
level", since the project mentioned does not even appear to meet the most
liberal possible interpretation of this term, which would be "shipped".

~~~
swannodette
etorrent, <https://github.com/jlouis/etorrent>

~~~
allertonm
Thanks, that does improve jlouis case quite a bit.

(And makes me sound a bit uncharitable too. Merry Xmas!)

~~~
jlouis
Too add: BitTorrent is heavily "multi-user" in the sense that you communicate
with numerous peers (200+ is not uncommon). Each peer gets turned into a small
set of processes inside etorrent (4 per peer), so it quite heavily makes use
of the process-parts of Erlang. I wouldn't say you need to have to be a
"server" in the usual sense to argue the point. In the case of BitTorrent the
client is also a server however.

------
Aloisius
What matters to me is that code never relies on one person or a small group of
people to maintain/improve it.

If a senior Python/C++/Java developer can open up the source code to some
Erlang program that is having problems and fix a bug, then awesome. I can hire
them by the boatload.

If I have to spend 2 months searching for a replacement for an Erlang
developer that quit, well, that's not good at all.

My feeling is that senior Erlang people aren't exactly abundant. I have a
friend who is flown around the world for Erlang contracting jobs simply
because he's a well known senior Erlang guy. That makes me nervous as an
employer.

~~~
thesz
>If I have to spend 2 months searching for a replacement for an Erlang
developer that quit, well, that's not good at all.

First of all, by requiring Erlang you will get mostly "above average"
programmers.

Second, your "senior Python guy" will still nede time to get into the problem
domain, from a week to half a year.

And third, any sufficiently capable programmer can peek Erlang to his own
productivity level in two weeks. If he has previous history of functional
programming - one week. Again, functional programming indicate "above average"
programmer, even plain _interest_ matters..

So you're better with Erlang than Python. I know, I was. ;)

I think that your "senior Erlang" friend just loves to change companies or
have talent for it.

------
mfukar
Great post! Let me just say that for a person like me, who hasn't really used
Erlang in large projects (mostly on small projects for fun), this post (as a
retort to the previous one) was a really insightful introduction to the
mentality behind/in Erlang.

One comment I've wanted to make about the initial post by Sudarshan Acharya
and his point about Erlang's syntax is the following: before delving into
functional languages, I had mostly experienced imperative & OO programming.
The syntax of any language doesn't really bother me: it's already unintuitive
enough that I have to learn _a new language_ , based on typed text, to tell
the computer what to do, that worrying about it / contemplating its reason for
existence isn't gonna help me in any way.

------
akkartik
I get pissed when noobs diss lisp for its parens, and yet I complain about
erlang's syntax. Mea culpa.

When I complain about its syntax I'm really thinking about its error messages.
Leave out a comma, or replace a period with a semicolon, and prepare to be
confounded. They take some getting used to, and I've never managed to get past
them in several attempts.

~~~
mattrepl
Erlang annoyed me in the same way. The syntax was fine, except for the comma
or semicolon and period issue. Made moving code a pain.

~~~
rvirding
I find that the actual moving of code is the _least_ of my worries when
writing a program. It's working out what to move which takes much longer time.

~~~
lelele
Some people - myself included - follow a style of developing code which
requires you continuously moving code around, therefore speed in doing that is
important. Does Erlang mode in Emacs understand Erlang's "sentences"?

------
joe_the_user
_The trick of OO-languages is “abstraction is had by introducing another
object”._ ... _In Erlang, the mantra is “abstraction is had by introducing
another process”._

OK, it is hard for me to imagine that creating another process wouldn't have a
larger conceptual overhead than introducing another object. Perhaps I just
haven't seen the magic yet.

\--

For me OO is far from a panacea. But does get some jobs done.

A big thing is the ability to construct multiple entities that can all be
treated effectively the same way because they all implement the same
interface. Your function happens to take Y structure. Suppose X inherits from
Y but does something differently - Voilà, you have abstracted away your
dependence from X. What would the Erlang equivalent to this be?

~~~
jerf
An Erlang process is arguably _more_ the object that Alan Kay had in mind when
he first conceptualized Object Orientation than what we today call objects.
Message passing as a paradigm is in my somewhat-experienced opinion really
neutered when there's still only one thread of control.

The following won't produce a _perfect_ Erlang design, but it's a start:

1\. Create your traditional OO design.

2\. Anything that isn't obviously a collection or glorified struct,
instantiate as a process and write them as gen_servers (or relevant other OTP
process instead).

3\. Anything that is obviously a collection, use one of the language's
collections instead; if you _really_ need typing on those, layer it on top
with a tuple. Anything that is obviously a glorified struct is a record with a
central module representing the "methods" as functions on the record.

Like I said, this won't out-of-the-box produce a great design, but the mapping
will actually get someone used to OO but not used to Erlang at least started
understanding how it works in practice. You've got several million-ish
processes to play with, and in most programs you will not need to exceed that;
that is the idea behind the comments I made about "collections" and "structs",
because while it's easy to have millions or yet more of bits of data you can
write a lot of programs with even "a few hundred" serves floating around.

You get polymorpismish by passing PIDs around as objects and implementing
interfaces, only this time it's literal server interfaces instead of syntactic
sugar. You get encapsulation by the fact that processes simply can not peek in
on each other; this is actually even more rigid than most OO languages, no
friends, no public, no sharing. Inheritance is pretty manual. So, two of the
three usual OO characteristics are there.

I find my designs end up in a way that I'm not comfortable calling strictly
OO, but if you used OO terminology and an OO diagramming language to show,
everybody would understand what you meant. Given the way inheritance has been
getting downplayed in the OO community anyhow, well, I wouldn't call Erlang an
OO language by any means but I use a lot more of the "OO mental machinery"
when I'm programming in Erlang than I do when I'm programming in Haskell. It's
not as foreign as you might think at first, there's a lot of crossover there.
Arguably it's a better OO language than the languages that wrote inheritance
into their syntax and runtime too hard, and arguably it's not, but it's an
interesting argument.

~~~
davidw
Great post, but if you put things into practice like "write them as
gen_servers", the resulting code will be way more verbose than something like
Ruby.

I think some way of creating 'object processes' with methods and state would
greatly benefit Erlang. I mean, if it's such a common pattern, why not make it
simpler, easier and possible with less boilerplate.

~~~
jerf
I think when selling Erlang it is best not to oversell the concision. Writing
something in Erlang _can_ be concise, but where you get the benefit is when
you write something in Erlang that really benefits from the libraries and
message passing. A gen_server may look somewhat verbose, but remember you're
getting the supervisor tree, code upgrading, and a variety of other things
with that. If you have to implement that in C it's going to really cost you.

But if you're just sitting there writing "algorithmic" code, well, maybe it's
a 2x or 3x advantage over C because you're not managing memory and the pattern
matching can be nice, but it's no Ruby or Python. You really only get the
5x-10x advantage over C(++) if you're playing to Erlang's strengths, it does
not have the generic ability to cut down code like well-written Ruby, Python,
Haskell, or other languages that pride themselves on being concise. In fact
Erlang's metaprogramming facilities are frustratingly thin if you're used to
having some around.

If you're interested, consider Lisp-Flavored Erlang, but I have no direct
experience with that. (That's because my primary Erlang is actually using it
at work, and while it's perfectly OK that I'm using it, I see it as
advantageous not to make it necessary for my successors to have to learn both
Erlang _and_ Lisp to work on my stuff. If I ever have a home project with
Erlang I suspect I'd lay one of the syntax replacements like LFE on top of it,
if only to play with it.)

~~~
davidw
> If you have to implement that in C it's going to really cost you.

I'm not sure C is a good language to compare Erlang with. I think the
competition these days goes from Ruby and Python to Scala and Java. I mean, if
you're not beating C in terms of verbosity (which Erlang does handily,
comparing apples to apples), and you're much slower, what's the point...

