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-servers
>
> 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-event-library/
Maybe Johan and Bryan can give us an update on the state of play?
What's the ETA to commiting into HEAD?
-- Don
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
