Want to add a functional language to my toolchest. Haskell or Erlang?

Question

I've been an OO/procedural guy my whole career except in school where I did a lot of logic programming (Prolog). I work on an amazing variety of projects (freelancer) and so I don't want the tools I know and understand to hold me back from using the right tool for the job. I've decided I should know a functional programming language.

I've narrowed the field to Haskell and Erlang. What are the pros and cons, advantages and disadvantages, and major trade offs of Haskell and Erlang? How do I decide in a rational way, which is the better path? This is a big time investment, so I'd like to chose wisely.

Is there a good case to be made for something else entirely? F#, Scala OCaml?

(BTW, I'm normally a Ruby/C/Obj.C guy, so I'm not terribly impressed or dependent on the JVM as a runtime. It's completely neutral to me. It's a fine runtime, I don't hold it for or against a language. I don't use Microsoft products though, so a .NET runtime would be a negative.)

UPDATE: Thanks for all the great feedback! After reading all the answers here, and thinking about it for awhile, and checking out the excellent Try Haskell and Try Erlang, I've decided to learn Erlang. Both seem like fantastic options, but as an old Prolog guy, the Erlang syntax seems more logical and readable and less foreign to me. I'm also pretty excited about Erlang's message based concurrency versus Haskell's transactional memory. As on OO guy, messaging just makes a lot of sense to me. Wish me luck!

Answer 1

If you want to build actual stuff, id go for Erlang. It has a decent amount of libraries and is mature and proven to work good in a production setting. Its built for zero-downtime concurrent systems.

If you mainly want to learn functional programming (and type-theory) then go with Haskell.

Both languages are designed well, and anyone would benefit from knowing both.

Answer 2

Haskell is a statically-typed, general-purpose purely functional language. It has the most powerful static type-system I know and forces you to program functionally. Its syntax is extremely concise and no side-effects are allowed without the type system noticing it.

You definitely get the best overview over functional techniques here (including lazy evaluation, monads, ...), but I can't promise it's the most productive tool for an actual job.

Erlang (and Clojure) is mainly built for parallel-processing and distributed computing (telecommunications, websites). They're dynamically typed and have high-level concurrency structures built-in (e.g. Actor model).

F# is impure - You can programm functionally if you want. It targets .NET, which it's fully interoperable with (as Scala with JVM/.NET). Its type system is quite advanced (but not as advanced as Haskell's) - It might be the most productive language for general-purpose applications here.

Answer 3

Haskell is the definitive functional language, given the attention it receives from the academic community. There will always be something interesting and cutting edge going on in the development of Haskell. It's also purely functional language by default (Erlang and the others you mention are not).

If you really want to dive into functional languages, and you're already used to Ruby or C, I'd recommend Haskell.

Edit: since you mention "building real stuff", the following article might be useful:

Haskell in Industry

Answer 4

Haskell teaches you a lot and gives you a totally different perspective on programming. It's really worth learning, not for being able to write Haskell programs, but for improving your programming and reasoning skills in general.

Erlang gives you less of this (still quite a bit), but for that is definitely a "real-world" language.

I would suggest at least learning the theory of Haskell (types, type inference, monads, laziness), if you don't wish to become proficient in Haskell programming.

Answer 5

Erlang is impressive if you have a high-volume application that needs to do parallel computations. The Erlang VM is second-to-none in this respect. The ability to do huge amount of multitasking seems amazing, but then when you get into the self-correcting abilities Erlang has, you will be even more impressed.

[Shameless Plug] I have a few entries in my blog about the Erlang VM and Erlang in general. Link in profile [/Shameless Plug]

I vote for Erlang.

Answer 6

Simon Peyton Jones (a founding figure in Haskell) gave a great talk entitled "Haskell and Erlang: growing up together" at the Erlang Factory meeting in 2009. There is video too. The presentation is remarkably balanced, discussing the different roads taken.

Answer 7

My unsupported and semi-informed opinion: Some mixture of Haskell, Erlang, and Clojure represents "the future" of programming languages. Not necessarily any of those languages themselves, but something inspired by what they've done. So really, you can't go wrong with those, I think.

In more concrete terms, I like Dario's answer, but I'll speak to a few practical details about Haskell:

• Haskell is a very expressive language with a steep learning curve. Unless you're coming from an ML background, expect it to take three times as long to become proficient with Haskell as with most other languages.

• Haskell currently has a very active and helpful community (e.g., compare the haskell tag on Stack Overflow to other functional languages). It's nice to not be alone in the world. Not to say that other languages don't have active communities--I just don't know--but Haskell definitely does.

• Much is made of Haskell's purity, but that's a distraction at best. The important thing about Haskell is the type system as a whole. In most static-typed languages the type system just gets in the way; in Haskell, the type system is expressive enough that you can encode non-trivial guarantees about the program logic^[0], thereby turning many classes of bugs into compiler errors. Constraining side-effects is an important, but over-hyped, subset of this.

• Haskell is very flexible with syntax and type constraints--not quite to the extent of a Lisp dialect, but it still makes an excellent "host language" for embedding domain-specific languages. Haskell also has at least three extant forms of metaprogramming support^[1], which is both a good and bad thing I suppose.

• Haskell is about as powerful and productive as languages such as Ruby or Python--you lose some dynamic flexibility, but you gain the bug-prevention and syntactic plasticity as above. On the other hand, compiled Haskell is dramatically faster than most dynamic languages, competitive with other garbage-collected, static-typed languages.

• Haskell has a very straightforward foreign interface to C and lots of pure-Haskell libraries for common tasks, so it's more than acceptable for any actual job that you could imagine writing in some mix of C and a higher-level language with C bindings. On the other hand, interfacing to other languages can be a crapshoot, so if you really need a particular library that doesn't have a good C interface, things could get ugly.

• Using Haskell effectively generally means abandoning OOP style, in case that bothers you. Haskell makes a fine faux-impure/imperative language, and of course is functional at heart, but good OOP style tends to clash badly and is best avoided. This isn't too bad, since functional idioms can subsume large sections of what OOP would be used for, but if you're used to OOP thinking it may be a painful adjustment.

[0]: In a few mostly-trivial cases, the type of a function so constrains the implementation that there is literally only one possible function with the desired signature, which therefore must be bug-free if it type-checks successfully (well, disregarding implementations that deliberately crash the program). People have even written "reverse type-checkers" that convert such function types into the functions they describe.

[1]: Namely: 1) "Scrap Your Boilerplate" and related approaches to datatype-agnostic programming, with limited forms of type introspection and whatnot; 2) Type-level metaprogramming, using a compiler flag to make the type-checker Turing-equivalent and writing "programs" that produce types as their output; 3) Template Haskell, which embeds regular Haskell code to run at compile time, generating code and applying transformations to the AST.

Answer 8

You might find this article interesting. The writer implemented a bitTorrent client (a fairly large project) in first erlang and then haskell. Some of the comparison is sort of specific to bitTorrent but I feel that most of it holds in general.

Answer 9

My contribution to the flame-war - Haskell is awesome because of:

• Purity
• Type system
• Type-classes

Let me put it this way: Does Erlang have something like Hoogle? Didn't think so. Case closed.

Let me explain, by example:

Let's say I'm implementing quick-sort and I want to separate my list to two parts, those smaller than the pivot and those greater or equal. Will I loop on those numbers to separate them to two groups like I would in, say, Python? Been there, done that. It would be boring to loop or recurse on it... Haskell's library probably has a "higher order function" to do it all for me.

The function I'm looking for will take a list of "A"s [a], a "conditional on As" a -> Bool and returns two lists of "A"s to me ([a], [a]).

Hoogle [a] -> (a -> Bool) -> ([a], [a]):

Prelude break :: (a -> Bool) -> [a] -> ([a], [a])
Prelude span :: (a -> Bool) -> [a] -> ([a], [a])
Data.List partition :: (a -> Bool) -> [a] -> ([a], [a])

So it finds three functions that fit this type (order of arguments doesn't matter), all of which do useful things; but here partition is what we want.

Instead of a boring loop, our code is:

(under, over) = partition (< pivot) nums

Hoogle is very cool, but it is only possible due to the sheer awesomeness of Haskell. In C a function like void mysteriousFunc(void) can do absolutely anything. In Haskell the types tell us a lot about the code, and the fact that the compiler type-checks our program already assures us quite a lot and may catch bugs a-plenty.

Answer 10

Haskell is a well thought-out, powerful language. Not just the broad strokes but also the details are right -- good module system, great package manager, nice error messages. You may not like indentational syntaxes; but as far as they go, Haskell's is well-implemented and clear.

Erlang gives you a lot more in the way of parallel programming than it offers for functional programming. As a language, it's pretty rough -- no hierarchical modules, goofy Prolog-derived syntax, awkward error messages. If you'd like to learn about how to organize and manage large multi-process systems, Erlang is a great start -- but that's not functional programming qua functional programming.

Many fine things about FP are only realizable in a typed setting. Bounded side-effects, marked by types, allow powerful optimizations; and rich, expressive types make libraries easier to work with and errors easier to catch. It says a lot that Erlang has bolted on type-checking with Dialyzer. Haskell is a practical, pleasant environment in which to explore typed functional programming.

Answer 11

So, erlang is used in production at some startups you may have heard of, e.g., facebook, heroku, reddit, github. MochiMedia just sold for 70 million or something and their core technology platform is erlang. Count that as a vote for "gets stuff done".

Answer 12

(This is just a note to leander's link to Peyton Jones' Haskell+Erlang talk, but I can't figure out how to make it one.)

It of course can't go very deep, but if you're wondering "Erlang or Haskell?" maybe you'd find some food for thought in the extended interview of Erlang designer Joe Anderson together with Peyton Jones; I think it was connected to Peyton Jones' Erlang Factory talk. You can extract a transcript from the page as well.