A response to "Erlang - overhyped or underestimated" | Hacker News Reader

A response to "Erlang - overhyped or underestimated"

jlouisramblings.blogspot.com

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]

Heh, not so fast, that's not first class access. Python has this problem as well, in order to have a uniform higher-order accessor to Objects, Lists, and Dicts, etc. you need to hack together some ugly functions. It's also why OpenStruct exists in Ruby. Same problems in JavaScript. Et al.

Not to be a ML/Haskell weenie, but dynamic languages aren't the only ones that don't require writing out every single damn type. We've had type inference since 1982, thanks to Hindley and Milner, and you get free compiler-enforced testing that your function arguments are of the proper polymorphic type.

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.

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.

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.

You're wrong. The code ratio is about 1/3, for large applications.

http://www.slideshare.net/Arbow/comparing-cpp-and-erlang-for...

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.

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.

To an extent, syntax is a superficial concern: for the most part, programmers can handle any syntaxes thrown at them even if there are certain ones that feel more natural to them. It isn't entirely superficial, though. A fidgety syntax is a distraction even for the experienced developer.

Regexps and a solid String implementation are just fundamental to general-purpose programming nowadays – for a good reason. Though pattern matching is nice too…

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.

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

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

A big departure, I should say.

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.

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.

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".

etorrent, https://github.com/jlouis/etorrent

Thanks, that does improve jlouis case quite a bit.

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

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.

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.

>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.

Pointy-haired boss thinking. What are you doing on HN?

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.

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.

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.

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.

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"?

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?

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.

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.

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.)

> 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...

Message passing, and pattern-matching on the message structures. Learning to use message-passing idiomatically is a huge part of programming Erlang.

Erlang is arguably more OOP (in Alan Kay's sense) than something like Java or C++, as it more directly implements late binding and message-passing.

Reply on news.ycombinator.com