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?
A:
I'm sure you can find people who think so, but I think you're mistaken about the ability of Erlang to support this kind of use; it's widely used in telephony applications, and is actually quite robust. Erlang is very much optimized to highly reliable, high concurrency servers.
Charlie Martin
2008-12-27 04:27:37
I guess I'm kind of confused by your reply - you start off saying I'm mistaken that Erlang can be used for something like making a game server, then ou finish by saying its optimized to handle reliable, concurrent servers?
ryeguy
2008-12-27 04:47:16
+2
A:
The question of whether Haskell is as good as Erlang depends on what people want from a language. I think both would do quite well as a game server, but it depends mainly on what you want or expect from a programming language. One of the easiest differences to note is that Haskell is a statically typed language with type inference, and Erlang is a dynamically typed language. Overall, I would say that Haskell requires a bit more "sophistication" for those not accustomed to functional programming.
faran
2008-12-27 05:11:07
+26
A:
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.
Norman Ramsey
2008-12-27 05:51:36
can you give some evidence for your claim about Haskell hitting a wall wrt threads sooner? With OS threads, perhaps... but what about Haskell threads?
ja
2008-12-27 07:53:19
my Erlang bubble burst a bit when I saw this: http://www.nabble.com/Chameneos.rednux-micro-benchmark-td19925134.html ... I verified the results on my boxes and they are correct, there seems to be some huge issue with SMP scalability and messaging. The GHC implementation performs much better...
mjy
2008-12-27 15:22:50
@ja: All my evidence comes from hallway conversations with the Erlang and GHC guys at ICFP (http://icfpconference.org). It is true that the GHC guys have spent the last year really gearing up for multicore and parallelism, whereas my impression is Erlang is now more in a commercialization phase.
Norman Ramsey
2008-12-27 20:28:15
GHC's last (?) thread scaling issue was squished a few months ago, and there's been a few reports of million+ threads without trouble. That said, the Erlang focus is much more on distribution, rather than shared-mem multicore.
Don Stewart
2009-04-13 00:53:41
+6
A:
Last time I looked, the libraries and frameworks for building scalable servers in Erlang looked a bit more mature than those for Haskell. I'd suggest looking at Programming Erlang: Software for a Concurrent World for information on those.
joel.neely
2008-12-27 05:56:05
+4
A:
The benchmarks of these papers show that Haskell can compete with Apache:
Developing a high-performance web server in Concurrent Haskell
Simon Marlow
http://research.microsoft.com/apps/pubs/default.aspx?id=67499
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):
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1391&context=cis_papers
ja
2008-12-27 07:50:35
+4
A:
It is a lot easier to introduce memory leaks in your Haskell application due to laziness. Long-running servers are precisely the kind of programs where you really don't want to have any memory leaks.
While I agree that Haskell is a more solid language and nicer to program in, Erlang is much easier and has many libraries specifically intended for uses like these.
I don't think there is a Haskell equivalent to, say, Mnesia, and writing it is going to be difficult. You can write Haskell versions of gen_server, gen_event, etc. but they won't have been optimised and tuned for over a decade.
Alexey Romanov
2008-12-27 13:56:00
Actually, memory leaks are impossible to introduce without using the FFI or something similar: all memory is accounted for by the garbage collector and can be recovered.What you are referring to are "space leaks," which means memory used for unevaluated thunks. Just evaluating them (or throwing them away) will free the memory.That said, dealing with this issue, since it's entirely unfamiliar to most programmers, takes a fair amount of work at first, and you should plan for it.
Curt Sampson
2009-05-18 09:53:32
Curt is absolutely right, a space leak is technically not the same as a memory leak, but they will behave the same way in many programs that iterate indefinitely. I would say that it is *much* easier to unwittingly introduce a space leak in a Haskell program than a memory leak in a C program, since it requires careful attention to lazy evaluation order, which is often unintuitive. That said I'm a Haskell noob -- I presume it gets easier with practice.
j_random_hacker
2010-07-05 10:20:33
+9
A:
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.
mipadi
2008-12-27 15:10:11
> it's actually a logic programming languageNo, it is not. There is no built-in search, you can't work with uninitialized variables, no full unification, etc.The syntax is Prolog-ish, and pattern-matching permits using the same variable on the left side (not on the right!), but it's functional.
Alexey Romanov
2008-12-27 19:03:07
+3
A:
Now there is a new option: use the Haskell/Erlang FFI to write your logic in Haskell and communicate using Erlang.
Alexey Romanov
2009-01-02 16:10:44