aran.donohue:
That's very interesting. I only brought it up because I'm thinking about the upcoming problems of real-time web application servers.
I'm sure many people have seen this blog post and Dons's replies: http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-serve...
The Haskell code codexon used isn't the best Haskell can do. But I think it's the clearest, most obvious code---the most like what someone learning from the ground up would try first. Ideally, it should run fast by default, and it's too bad that you need to learn about bytestrings (and choose between lazy vs. strict), the various utf8 encoding options, and a new event library to make it perform. Since I'm basically a beginner to Haskell, if I were to set out to test out a WebSocket server in Haskell, my first pass code would probably look a lot like the codexon template. I certainly wouldn't want to go multi-process nor explicitly manage cores within a single process. I would want forkIO to just work.
Would you write the Python solution though, as a naive Python user? It's scripting epoll-- which is a pretty specialized use. Anyway, I encourage people to use the event lib, even before the forkIO support is merged in. It's a lot of fun, http://donsbot.wordpress.com/2010/01/17/playing-with-the-new-haskell-epoll-e... Maybe Johan and Bryan can give us an update on the state of play? What's the ETA to commiting into HEAD? -- Don