\$\begingroup\$

I've spent the last year developing a commercial game engine in Haskell, and for us, the experience has been overwhelmingly positive. Our game world is complex, and Haskell has made it easy to model the process of conversion from an editor format to a game engine format. I would hate to think what that code would look like in an imperative language.

Space leaks have come up on occasions, and while they've caused a bit of trouble, in the general scheme it has been a small amount (for example as compared with finding deadlocks in a similarly sized Java projects), and once they were fixed, they stayed fixed.

We are using FRP similar to Yampa, and there's certainly a learning curve associated with it, but once that's over with, the experience is very positive. Libraries have not been a problem for us - everything we've needed has been available. Garbage collection delays were a particular issue since it's for an embedded platform. We've used some C++ to manage the animation. Performance has also been an issue with this being an embedded platform (= slow processor). We've done some C and we're also looking at emerging Haskell technologies like accelerate. The C++ animator was a design decision early on and the places where the code is too slow are only very small areas. In the long run, we want to translate all our C to Haskell.

Haskell has made a difficult job easy, and all the difficulties I've just mentioned have been tiny in comparison to the large amount of complex code we've produced that is clean, maintainable and pretty much unbreakable. Parallelism will be an issue in game development very soon, and we are extremely well placed to deal with it. Some of what I've said may not apply to small projects, because we are in this for the long haul, so start-up costs like learning curves, library support, etc, are much less of an issue.