Haskell for a server?

Question

With regards to making a game server, it seems Erlang always comes up as a language that is "built for this kind of thing" with its scalability and concurrency features. I don't have experience in either Haskell nor Erlang, but on the surface they seem the same. Looking into Haskell's docs it seems like it has support for multiprocessor scalability and concurrency, and Haskell is said to be a more solid language and has a visibly better community. My question is, then, is Haskell considered to be as good of a solution to server building as Erlang supposedly is?

Answer 1

It depends what you want to do with your server. As might be expected from a telecoms application, Erlang excels at doing simple tasks with very high concurrency. If your server will need a bazillion connections per second, or at once, Erlang is your friend. Erlang also offers better support for distributing load over multiple servers.

Haskell excels at complex, symbolic computation and as of April 2009 can also handle a great many threads (see update below). Moreover, Haskell has more tools for getting complicated code right: things like QuickCheck, SmallCheck, and the static type system. So if your server is doing complicated, interesting things and you can get by with just one server, you're probably better off with Haskell.

---

Update 13 April 2009: Don Stewart, a reliable source, reports that "the last thread-scaling bug in the Glasgow Haskell Compiler was squished a few months ago", and that some users report using a million Haskell threads without trouble. As of January 2009, there is a new, unpublished paper from the implementors which may describe how this is achieved.

---

Update 21 February 2012: John Hughes's company, QuviQ, now makes QuickCheck for Erlang. They have found a number of very interesting bugs. You can download "QuickCheck Mini" for free; it is comparable to the Haskell QuickCheck. There is also a more powerful commercial version.

Answer 2

The benchmarks of these papers show that Haskell can compete with Apache:

Developing a high-performance web server in Concurrent Haskell
— Simon Marlow

Combining Events And Threads For Scalable Network Services: Implementation And Evaluation Of Monadic, Application-level Concurrency Primitives
— Peng Li Stephan A. Zdancewic (see Figure 19)

Answer 3

I don't have experience in either Haskell nor Erlang, but on the surface they seem the same.

There are some pretty stark differences between Haskell and Erlang. Erlang is specifically designed for concurrent systems. The language and virtual machine are both designed to support many, many processes, and Erlang uses an actor-style system to manage communication between all of them. Haskell also supports concurrency fairly easily, due to its functional nature, but it's still a bit harder to do concurrent programming in Haskell, and the language isn't specifically set up to facilitate this.

Like Haskell, Erlang doesn't share state between processes, so it's easy to write multi-process software. But the programming style between Haskell and Erlang is a bit different, since Erlang emphasizes the use of small processes to perform concurrent processing.

I love Haskell -- it's one of my favorite languages -- but if I was going to write server software, I'd probably use Erlang. But it's certainly possible to write a server in Haskell, if you know Haskell better or find the library support to be superior.

Answer 4

Now there is a new option: use the Haskell/Erlang FFI to write your logic in Haskell and communicate using Erlang.