Why did you decide "against" using Erlang?

Question

Have you actually "tried" (means programmed in, not just read an article on it) Erlang and decided against it for a project? If so, why? Also, if you have opted to go back to your old language, or to use another functional language like F#, Haskell, Clojure, Scala, or something else then this counts too, and state why.

Solution 1

I returned to Haskell for my personal projects from Erlang for the simple virtue of Haskell's amazing type system. Erlang gives you a ton of tools to handle when things go wrong. Haskell gives you tools to keep you from going wrong in the first place.

When working in a language with a strong type system you are effectively proving free theorems about your code every time you compile.

You also get a bunch of overloading sugar from Haskell's typeclass machinery, but that is largely secondary to me -- even if it does allow me to express a number of abstractions that would be terribly verbose or non-idiomatic and unusable in Erlang (e.g. Haskell's category-extras).

I love Erlang, I love its channels and its effortless scalability. I turn to it when these are the things I need. Haskell isn't a panacea. I give up a better operational understanding of space consumption. I give up the magical one pass garbage collector. I give up OTP patterns and all that effortless scalability.

But its hard for me to give up the security blanket that, as is commonly said, in Haskell, if it typechecks, it is probably correct.

Solution 2

We use Haskell, OCaml and (now) F# so for us it has nothing to do with lack of C-like syntax. Rather we skip Erlang because:

• It's dynamically typed (we're fans of Haskell's type system)
• Doesn't provide a 'real' string type (I understand why, but it's annoying that this hasn't been corrected at the language level yet)
• Tends to have poor (incomplete or unmaintained) database drivers
• It isn't batteries included and doesn't appear to have a community working on correcting this. If it does, it isn't highly visible. Haskell at least has Hackage, and I'd guess that's what has us choosing that language over any other. In Windows environments F# is about to have the ultimate advantage here.

There are probably other reasons I can't think of right now, but these are the major points.

Solution 3

The best reason to avoid Erlang is when you cannot commit to the functional way of programming.

I read an anti-Erlang blog rant a few weeks ago, and one of the author's criticisms of Erlang is that he couldn't figure out how to make a function return a different value each time he called it with the same arguments. What he really hadn't figured out is that Erlang is that way on purpose. That's how Erlang manages to run so well on multiple processors without explicit locking. Purely functional programming is side-effect-free programming. You can arm-twist Erlang into working like our ranting blogger wanted, adding side effects, but in doing so you throw away the value Erlang offers.

Pure functional programming is not the only right way to program. Not everything needs to be mathematically rigorous. If you determine your application would be best written in a language that misuses the term "function", better cross Erlang off your list.

Solution 4

I have used Erlang in a few project already. I often use it for restful services. Where I don't use it however is for complex front end web applications where tools like Ruby on Rails are far better. But for the powerbroker behind the scenes I know of no better tool than Erlang.

I also use a few applications written in Erlang. I use CouchDB and RabbitMQ a bit and I have set up a few EJabberd servers. These applications are the most powerful, easiest and flexible tools in their field.

Not wanting to use Erlang because it does not use JVM is in my mind pretty silly. JVM is not some magical tool that is the best in doing everything in the world. In my mind the ability to choose from an arsenal of different tools and not being stuck in a single language or framework is what separates experts from code monkeys.

PS: After reading my comment back in context I noticed it looked like I was calling oxbow_lakes a code monkey. I really wasn't and apologize if he took it like that. I was generalizing about types of programmers and I would never call an individual such a negative name based on one comment by him. He is probably a good programmer even though I encourage him to not make the JVM some sort of a deal breaker.

Solution 5

Whilst I haven't, others on the internet have, e.g.

We investigated the relative merits of C++ and Erlang in the implementation of a parallel acoustic ray tracing algorithm for the U.S. Navy. We found a much smaller learning curve and better debugging environment for parallel Erlang than for pthreads-based C++ programming. Our C++ implementation outperformed the Erlang program by at least 12x. Attempts to use Erlang on the IBM Cell BE microprocessor were frustrated by Erlang's memory footprint. (Source)

And something closer to my heart, which I remember reading back in the aftermath of the ICFP contest:

The coding was very straightforward, translating pseudocode into C++. I could have used Java or C#, but I'm at the point where programming at a high level in C++ is just as easy, and I wanted to retain the option of quickly dropping down into some low-level bit-twiddling if it came down to it. Erlang is my other favorite language for hacking around in, but was worried about running into some performance problem that I couldn't extricate myself from. (Source)

View more solutions

Comments

[yazz.com]

Did you try any of the Java/Erlang bridges out there?

[yazz.com]

Wow, I dod't even know that Erlang ran on the IBM Cell BE processor. So is Erlang best for large memory environments?

[Will]

Erlang is an excellent choice for high-reliability high-transaction environments. Chances are, phone calls you make all go via Erlang-based switches. And its increasingly common in internet servers, such as MQ and Jabber.

[oxbow_lakes]

Nope! I really liked scala from the start so saw no need to look further afield

[Konrad Rudolph]

Didn’t Joe Armstrong specifically write an Erlang adapter for the X windows protocol? I had thought that writing GUIs in Erlang would actually be quite easy.

[oxbow_lakes]

I'd looked at Ruby and Groovy a little. Erlang looks so alien to anyone used to the C language-family; I discounted it early on

[Jonas]

Yes, you can write GUI in Erlang. But it's tricky if you want something more advanced like WPF.

[Rayne]

A lot of languages don't look like C. How is that a real pro or con in any case? I certainly understand syntactical preferences, but I'm not sure I see how that is a real reason to completely disregard a language.

[Rayne]

I think the whole "It doesn't look like C so is therefore bad" was a bit worse than the JVM bit. It's all just a little silly if you ask me. But nobody is asking me, so I should just keep quiet in my corner. ;)

[oxbow_lakes]

I should have been more explicit - if one has been working in C-like languages for >10 years, a completely alien syntax is, um, alien and daunting.

[Konrad Rudolph]

Notice that Haskell doesn’t even need the write-compile-execute cycle since it supports REPL (e.g. via ghci). For me, that unites the best from the worlds of static (~ally typed) and dynamic languages.

[Daniel C. Sobral]

These are good reasons and all, but have you actually programmed in Erlang? The question was directed at people who actually tried it out.

[Daniel C. Sobral]

@Konrad Haskell's REPL has limits, however. For one thing, you can't write data definitions in it. You need to write it to a file, and have the REPL process that. Both ghci and hugs.

[oxbow_lakes]

It's a fair point - I decided not to because of the reasons above. IMHO they are probably the same reasons most people from a Java background have for not making such a change

[Edward Kmett]

@Daniel Fortunately, given the nature of what I do, most of the time when I want to work in a REPL, I can turn to a bunch of Functor/Bifunctor combinators from category-extras to build up the data type I need. That said, there is at least one set of ghci macros out there that can load data definitions dynamically during the session by appending to a temporary Haskell source file for you and reloading it.

[oxbow_lakes]

@Rayne - I see you are 16. I presume this means you : 1) don't have 10 years worth of legacy code you're not keen on throwing away and 2) aren't afraid of new things, unlike old codgers like me

[ZJR]

Some good points there, but the overall answer reads "I decided against it because I really like java" to me.

[Daniel C. Sobral]

@Rayne Sheesh, cool down. Chris wasn't attacking you. Much on the contrary, he simply stated that, by virtue of being younger, you haven't been doing the same for for as long, and are much adaptable to change. If anything, he is treating your age as an advantage. One which he doesn't share any longer, so his perspective on things are different. Consider, for instance, driving. Someone who has driven in the US for 30 years is going to have much more trouble adapting to driving in the UK than someone who has just started driving.

[Rayne]

@Daniel - Heh. I misread his 2) point. In my defense, it sounded like an attack the way I read it. I apologize for overreacting. Guess it's my inexperience. ;)

[Adam Lindberg]

Erlang has had years of effort put into it (and it's GC) for 24 years.

[Shaun]

Oh yes, plenty - though never for a production application. When evaluating a new technology, it helps to build some in-house tools with it first. We like Erlang, and have no problem running products that use it such as RabbitMQ, but prefer the technologies listed above for the reasons already outlined.

[Jonas]

Good point! I have heard that it's tricky to add a type system to Erlang, mainly because of the Hot Code Swap. Armstrong and Peyton Jones talk about types in Haskell and Erlang in this interview: infoq.com/interviews/armstrong-peyton-jones-erlang-haskell

[oxbow_lakes]

@ZJR - the answer is not I really like Java (on the contrary, I now do everything in scala), but I really understand the JVM! Java and the JVM are not the same thing!

[Rayne]

@oxbow_lakes I see your point. I'm in the same boat, on the other side of the island. People don't understand how one can like the JVM but dislike the language it was created for. Clojure (and Scala for that matter) are great additions to the JVM, and I wouldn't use Java unless forced to at gunpoint. :D

[Konrad Rudolph]

@Sanoj: thanks for linking the interview, it rocks. I’m reading Seibel’s “Coders at Work” at the moment where both have a say but having them next to each other is just incredible. To quote a /. limerick: +5 (insightful) – xkcd.com/301

[I GIVE TERRIBLE ADVICE]

What's your opinion on dialyzer and TypEr when it comes to having a type system in Erlang? Granted it's not the same (Success Typings rather than Hindley-Milner Type inference), but in my experience it does a good job on preventing software defects.

[Edward Kmett]

The success typing approach is something I've been spending a lot of time playing with in another environment -- the concepts are weakly similar to Dana Xu's ESC/Haskell or Neil Mitchell's Catch. They are definitely better than nothing! Any time you add a type check/inference pass you prove theorems (even weak ones) about your code and most broken code will fail even fairly simple checks. My general opinion of them is that they are useful and fit the flavor of the language, but due to the platform they can't go far enough for me to feel the same level of safety.

[MSalters]

Phone switches are a good breeding ground for languages. AT&T Bell even spawned two mainstream languages, C and C++. And their phone switches for a large part of the 90s had the highest FCC measured reliability. But the learning curve to get there was quite high.

[Warren Young]

rand() makes for an interesting study in function design. Many standard C library functions are non-reentrant, rand() among them. A lot of C library implementations provide reentrant alternatives, for good reason. (The C library on the machine I'm using now provides the purely functional reentrant rand_r(), for instance.) Erlang does provide the C-like random:uniform(), but also the purely functional random:uniform_s(). One should use the version that makes the internal state explicit in both languages.

[L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳]

secure.wikimedia.org/wikipedia/en/wiki/… "A function assigns exactly one value to each input of a specified type."

[Zachary K]

I rather like Haskell's type system, but it has a cost. It would not be possible to have a Typed Erlang because if you do then it would be impossible to upgrade a cluster. Because those nodes that had upgraded would not be able to talk to those that had not, as the types would not match.

[Edward Kmett]

The idiom being explored by cloud haskell is to use serialization for the channel format, but yes, hot swapping is much harder.

[Cetin Sert]

@DanielC.Sobral latest ghci (7.4 sth.) now supports everything in the language, including ADTs!

[Daniel C. Sobral]

@CetinSert Thanks! Haskell Platform doesn't have it yet, but there should be a new one out this week. I was thinking of going for Haskell again, and this gives me a nice little push.