top | item 2038392

Erlang - overhyped or underestimated?

42 points| gnosis | 15 years ago |sacharya.com | reply

38 comments

order
[+] necubi|15 years ago|reply
This article reads like "yeah Erlang has a lot of cool features, but it's really scary to an OO programmer like me."

> I can’t imagine how you can organize large code-bases in Erlang or even work as team, and this doesn’t feel right to any OO programmer.

Well, yeah, but neither would Clojure or Haskell or a host of other interesting and useful languages. Functional programming is a completely different paradigm, and if you come into with an OO mindset the results will not be good. But that's more a fault of the programmer than the language.

[+] thesz|15 years ago|reply
To quote Joe Armstrong: "As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully)."

http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

Erlang is closer to original Smalltalk than most of current OO languages: there are processes (objects) which communicate by messages (messages).

I also should mention OOHaskell: http://homepages.cwi.nl/~ralf/OOHaskell/ "In the second and major phase, we systematically substantiate that Haskell~98, with some common extensions, supports all the conventional OO features plus more advanced ones, including first-class lexically scoped classes, implicitly polymorphic classes, flexible multiple inheritance, safe downcasts and safe co-variant arguments. Haskell indeed can support width and depth, structural and nominal subtyping. We address the particular challenge to preserve Haskell's type inference even for objects and object-operating functions. Advanced type inference is a strength of Haskell that is worth preserving. Many of the features we get ``for free'': the type system of Haskell turns out to be a great help and a guide rather than a hindrance."

So everyone "can has" his OO everywhere, in case one needs it.

[+] defen|15 years ago|reply
I think 4 could be a legitimate concern - if there are no good resources for you to learn from, you don't want to accidentally put your company into a position where you have an unmaintainable code base because of a "known unknown". However these days we have the wonderful open source code being put out by the Basho people as a useful guide, so it's no longer a problem with Erlang.
[+] smackay|15 years ago|reply
My take on that sentence was not that author was comparing functional with object-oriented but rather the available tools and other infrastructure necessary to manage teams of developers and deploy code.
[+] joe_the_user|15 years ago|reply
The argument seems slightly different a standard "this isn't what I'm used".

It's more like "I know how OO allow teams to work together. I don't know how functional programming does that".

What would be the answer to that?

[+] chunkbot|15 years ago|reply
Obliged to respond, even if this is from two years ago, as a lot of our work is in Erlang... 1) is completely wrong; Erlang doesn't have anything to do with Prolog, and the syntax is actually pretty straightforward. 2) is for the most part true, though the bigger problem is finding one library that solves your problem (rather than choosing from two or more). 3) is mostly true (there are plenty of Erlang charlatans; try hiring for an Erlang position and see what manner of Erlang programmers you find). 4) is completely false; large (100K to 1M+ SLoC) Erlang codebases are manageable. 5) could be a good point, but might be said about any language; in the end, results speak for themselves. 6) might be a valid concern, but for the most part, Erlang code is behind the web layer, and some other application relays the requests to the back-end.7) is pretty much irrelevant.

At the end of the day, if you're happy with the results you're getting with Erlang (and you can get great results), who cares if the rest of the world thinks Erlang has no fashion sense? Erlang is still beautiful.

[+] xtho|15 years ago|reply
"ad 1.)" is completely wrong: From http://www.erlang.org/faq/academic.html:

    10.3  Where does Erlang syntax come from?
    Mostly from prolog. Erlang started life as a modified prolog
Maybe this means Prolog syntax isn't really that weird?
[+] jasonwatkinspdx|15 years ago|reply
Erlang was originally a Prolog dialect. To be specific an external dsl for concurrency implemented on top of a Prolog interpreter.

The language moved on and dropped some of the defining features of Prolog (such a backtracking), but the syntax still resembles Prolog.

[+] waterlesscloud|15 years ago|reply
"1. Today’s mainstream developers who are used to C or Java like syntax wont find its Prolog-like syntax too friendly. Unless you started programming since the 80’s & 90’s and are used to languages of similar syntax, it will take quite some time before you get comfortable with Erlang’s weird syntax. I never felt too comfortable with the syntax."

Huh? And...huh? It's not prolog like, and it's not like anything mainstream from the 80s and 90s. What am I missing here?

[+] prospero|15 years ago|reply
The syntax is absolutely based on Prolog, as evidenced by the significant capitalization and the mixed semicolons and periods.
[+] defen|15 years ago|reply
I think it's a misunderstanding based on the fact that Erlang was originally implemented in Prolog, so in some ways the language features are superficially similar - pattern matching and single assignment come to mind. Regardless of where it came from, though, it really is ugly. But it does get the job done, and the rules aren't that hard to learn. They're actually pretty simple, and with the right emacs mode it's pretty hard to mess up.

http://www.sics.se/~joe/pubs/prac_appl_prolog.ps

[+] cageface|15 years ago|reply
Is anybody looking for Erlang people? I passed on a job in Stockholm doing Erlang ten years ago because Erlang seemed like a very small niche, even if the platform does make some otherwise very difficult things easy.

It was kind of sad, actually, to hear Jonas Boner talk about Erlang at one of the Bay Area Scala group meetings. He said he fell in love with the language but realized it was too hard to get people to deploy Erlang so he's trying to build the same functionality in Scala with the Akka library.

[+] jacktang|15 years ago|reply
We had adopted Erlang in the real-time trading system and it is online now. However I hope mnesia will break 2G limitation in the near future.
[+] billiob|15 years ago|reply
The limit is on disk-only tables (due to Dets using 32-bit file offsets). The limit of on-memory tables is 16 exabytes on 64-bit systems.
[+] zephjc|15 years ago|reply
Someone in the comments mentioned Lisp Flavored Erlang (LFE) which seems interesting, and appears to live on (in relative obscurity) at https://github.com/rvirding/lfe

Friendlier macros is a win at the very least!

[+] HowardRoark|15 years ago|reply
This article was written in Nov 2008. Quite a lot has happened in the Erlang world since.
[+] gtani|15 years ago|reply
The Nov. 2008 release was R12-B5

Unfortunately, the release notes are enormous docs.

Fortunatley, each reflects a huge number of new features, bugfixes and enhancements.

Off top of my head:

- continuing work on tools like Dialyzer, McErlang, quickCheck

http://erlangotp.com/wiki/analysis/

- new SSL module

- NIF's

- Ericsson puts the repo onto github, starts pulling patches

- "erl +native" / HiPE

- schedulers for SMP processing

- large shared data structures passed as messages:

- from Basho: riak, rebar and Nitrogen

- Oreilly and Manning books (Cesarini/Thompson an outstanding book; archaelus and Gerakines were writing books also,hope they get published)

- learn you a erlang, erldocs.com,

http://learnyousomeerlang.com/

http://erldocs.com/

- the community has not changed. Beginner questions are still enthusiastically answered on IRC, the google group and stackoverflow (by Armstrong, Virding and the Ericsson core team, among others)

[+] rvirding|15 years ago|reply
I do get tired of the Erlang syntax complaints. Why should a language syntactically look like another language if the semantics are different? Erlang and Java are very different languages so why should they look the same? IMAO this will be even more confusing than having to learn a new syntax. When teaching Erlang we have problems with '=' and that though it looks a assignment it is really a match with completely different semantics.
[+] kungfooguru|15 years ago|reply
'3. Only a few people have written production level codes and you rarely get to hear from them.'

Well thats just not true...

[+] fingerprinter|15 years ago|reply
Feel the need to respond a bit since I've worked on an Erlang system of some significance.

1. Erlang has a funky syntax; deal with it. If you can't or won't learn the language b/c of the syntax that is your loss. I'm sorry, but I can't really find this a valid argument as it basically sounds like "Erlang syntax scares me. Me no likey".

2. Documentation on Erlang libraries is a bit weak in some areas, but all the source is there and since it is functional, the ability to decipher the methods is really great. However, if you are looking for a 'mysql tutorial' with a 1000 hits on Google to show you the way, you won't find it. Frankly, you will have to exert some effort with Erlang.

3. This is wrong. I realize that this is 2008, but even in 2008 you had huge Erlang systems at Akamai, Mochi and many European telecoms. Since then (when I have picked it up) there is Basho, XMPP implementations, trading systems and, of course, Facebook chat.

4. Again, fear basically. The code base likely will never grow as big as a .NET or JEE code base simply b/c the code is functional.

5. The numbers are the numbers and they speak for themselves. You can't really understand the benefit you can get from Erlang until you try it for yourself on a multicore system and see it fly, watch it in a multi-noded system and watch it grow and see how it handles failures w/ ease. Traditional OO developers (.NET and Java) just won't "get it" until they try it.

6. Red herring. Erlang is NOT a web language. But, since this article was written many have emerged. Chicago Boss, Nitrogen, Erlang-web. I still think of Erlang has mostly an way to (coupled with Webmachine) expose some endpoints as services for me to talk to.

7. Yeah, this one is true. String manipulation sucks. Binary manipulation, however, is awesome. Tradeoffs. Remember what Erlang is good for and what it is not good for and you will be quite happy with it!

Erlang, in general, takes some time to learn. It is well worth the time if you need infrastructure that can scale massively.

Lastly, I would like to say this...functional programming in general is coming back in vogue at the moment and for good reason. Working on this system using Erlang has really reshaped my thoughts on programming in the past two years and I have to say that all my code is cleaner, my code base is smaller I have started to really take a critical look at my OO code as heavy weight and not worth the overhead in many cases. FP also seems to map better to my way of thinking....but that might just be me.

[EDIT] - Clarifying 6 a bit. I think that holding the web framework argument against Erlang is unjustified. Even so, web frameworks have emerged. I find they don't map very well and I feel there are better solutions than using Erlang web frameworks.

[+] foljs|15 years ago|reply
> 1. Erlang has a funky syntax; deal with it. If you can't or won't learn the language b/c of the syntax that is your loss. I'm sorry, but I can't really find this a valid argument as it basically sounds like "Erlang syntax scares me. Me no likey".

And this is invalid, how?

A well designed syntax is a must for a good language.

If Erlang has a "funky syntax" (your words), then that is a real disadvantage that should raise concern. Syntax affects code readability, maintenance, etc.