Erlang - overhyped or underestimated? | Hacker News Reader

Erlang - overhyped or underestimated?

sacharya.com

42 pointsgnosis38 comments

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.

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.

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?

functional programming and in particular erlang is pretty much a godsend for working with a large codebase.

erlang is designed around intercommunication, there was some rule about how a team of 3 would make a 3 pass compiler, in erlang everything is explicitly isolated and you have to design specifically how the various parts of the system communicate with each other

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.

Don't really know Erlang, but having worked for Telecom industry earlier, I would guess Erlang is getting its concepts and messaging model from SDL [1] rather than from OO.

[1] http://en.wikipedia.org/wiki/Specification_and_Description_L...

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.

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.

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

Erlang syntax is derived from Prolog syntax, sure, but with several extra operators and heavy operator overloading. Prolog syntax is cleaner.

The ";" vs "." thing is also on Erlang. Prolog has a function to read the next clause (much like Lisp's read parses the next sexp), and Prolog clauses end in ".". The Erlang interpreter seems to have been implemented so it read every alternative for a pattern in one step, so it ended all except the last with ";". ";" is Prolog's "or" operator, "," is "and". Prolog just ends every pattern with ".".

That said, you get over those minor syntactic issues pretty quickly, and I'll take a language with ugly syntax but beautiful semantics over one with ugly semantics any day.

I'll take a language with ugly syntax but beautiful semantics over one with ugly semantics any day.

Sadly the erlang semantics aren't all beautiful either, at least for the things that most people would use it for today.

This quote that I picked up on the erlang mailing list was an eye-opener to me (from memory):

   Erlang wasn't designed to make easy things easy.
   It was designed to make hard things possible.

This explains a lot about the erlang mindset. Things like the obscure syntax or the abhorrent string handling are simply not very high on their priority list.

For example, strings weren't used much in the telecom projects that erlang was original conceived for - hence they didn't get much love until recently.

Similarly the syntax seemed like a good fit for the problems that erlang was looking to solve, because it makes the expression of very complex, concurrent constructs comparably sane.

The problem for us "normals" is that in our codebases we very rarely need that kind of expressive power (and the associated learning curve). We tend to need it in 2-3 critical spots, the remaining 99% is best solved by a general-purpose language that allows for quick iteration.

Introducing the behemoth of erlang to a project only for these 2-3 spots very rarely passes a cost/benefit analysis.

That's why we hack shoddy, slow and fragile bandaids in our go-to languages, instead of using erlang.

The string handling is not great* , but the support for pattern matching on atoms and tuples is nonexistent in most languages, and most programmers don't know to hold that against them.

* Except for the bit syntax, but that's more for binary data.

This isn't interesting anymore; Erlang and Prolog simply aren't related beyond the most superficial of syntactical rules. http://stackoverflow.com/questions/3542891/erlang-programmin...

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.

In erlang's pattern matching syntax, arguments given at run time are matched successively against number and types of formal parameters in each ";" separated clause in a function definition (plus against any guard's specified values).

This is similar to the syntax in haskell, F# and ocaml, so it may look weird at the outset but it's not an isolated weirdness, and it quickly becomes a natural way to read code.

Plenty of languages were initially prototyped in C, but we don't consider them "based on C" because they kept braces. http://stackoverflow.com/questions/3542891/erlang-programmin...

The language has very definitely moved on and lost ALL of the defining features of Prolog except for some syntax elements. It only resembles Prolog in a very superficial way, mainly that variables start with a capital letter. The semantics are completely different.

4) I remember seeing somethig that compiled LoC totals for the major erlang projects, and they were very compact repo's. I can't find it right now, but e.g. rabbitMQ core is ~12K, couchdb is 20K incl. javascript (ejabberd is a much bigger repo)

http://www.rabbitmq.com/resources/RabbitMQ_Introduction.pdf

http://en.oreilly.com/mysql2011/public/schedule/detail/17618

PS / FWIW / TBH ohloh has higher LoC counts by including tests and utility code, but something funky is goig on with their counts of riak LoC

http://www.ohloh.net/p/riak/analyses/latest

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

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

The syntax is absolutely based on Prolog, as evidenced by the significant capitalization and the mixed semicolons and periods.

This statement only reflects a poor understanding of what it means to be "based on Prolog". I know Prolog well, and use Erlang every day, and I can tell you that they share nothing in common beyond the most superficial of commonalities. http://stackoverflow.com/questions/3542891/erlang-programmin...

I'm currently reading this Erlang and OTP in action http://www.amazon.com/Erlang-OTP-Action-Martin-Logan/dp/1933... and its pretty good so far, gets into the meat of Erlang quickly.

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.

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.

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.

On-memory tables. But what would you do when you need to restart the program, or the entire system? Or can you persist the on-memory on disk somehow?

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!

This article was written in Nov 2008. Quite a lot has happened in the Erlang world since.

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)

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.

'3. Only a few people have written production level codes and you rarely get to hear from them.'

Well thats just not true...

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.

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

"funky" basically means "not c style"

erlangs syntax is very well thought out, I would even agree it is ugly at times, but it very purposefully avoids any fancy contructs choosing readability every time, erlang (imo) is by far the most readable language around, it is very very hard to find a piece of erlang code that is hard to follow because it only has primitive constructs

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

Well designed and 'understandable at first sight' are not synonymous. If they were, C would not be a good language. Many C programmers tend to forget how alien the syntax looked to them when they first met 'Hello, world!' in C, with its '#include' 'char * * argv', and braces for blocks.

a rebuttal already: http://jlouisramblings.blogspot.com/2010/12/response-to-erla...

Reply on news.ycombinator.com