[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
manlio_perillo at libero.it
Fri Jan 9 07:28:04 EST 2009
Bryan O'Sullivan ha scritto:
> On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <manlio_perillo at libero.it
> <mailto:manlio_perillo at libero.it>> wrote:
> Another example is the multipart parser:
> -- | Read a multi-part message from a 'Handle'.
> -- Fails on parse errors.
> hGetMultipartBody :: String -- ^ Boundary
> -> Handle
> -> IO MultiPart
> hGetMultipartBody b h =
> s <- BS.hGetContents h
> case parseMultipartBody b s of
> Nothing -> fail "Error parsing multi-part message"
> Just m -> return m
> Yes, that's definitely on the scary side of things.
> However, you don't have to go all the way to drinking the Iteratee
> Kool-Aid in order to write safer networking code that is still
> performant. Here are a few projects I'm actively working on in this area:
> * I'm adding epoll support to the threaded RTS. This is a necessity
> for server performance.
How easy is to add support for other methods, like poll, kqueue,
/dev/poll and Windows IOCP?
> * I've added support for sending and receiving lazy ByteStrings to
> Johan Tibbell's network-bytestring library. A quick benchmark with
> a toy HTTP server has shown this to be about 2x faster than
> writing ByteStrings to a Handle (i.e. 14,000 requests per second,
> vs 7,000).
I personally like Nginx concept of chained buffers.
They are basically a linked list of buffers, where each buffer can be
1) an in memory buffer, where you have pointers to the start, end and
2) file buffer, where you have a file descriptor and the current file
This is a nice abstraction, since, as an example, a file based buffer
can be sent to the network directly using sendfile.
I think it should fits well with ByteStrings.
> * I've got a continuation-based resumable parser combinator module
> for attoparsec in progress, which uses lazy ByteStrings for
> blazing performance. You can use this to write protocol parsers in
> a completely clean way, decoupled from the underlying network
> receive operations.
This is interesting.
Writing clean protocol parsers is one of the things I think Haskell can
be great with.
> While much of this isn't quite ready for use yet, this just represents
> one person's work, and there are lots of people beavering away actively
> at corners of the problem space that interest them.
Well, I have no doubts that good networking can be done in Haskell.
The problem is time.
Erlang (and Twisted, from the Python world) have already years of use.
So, if I need to write *now* a network application, should I *invest* in
Haskell, or should I just *use* Erlang?
As a counter example: I really don't like SQL.
However I have to use it, if I don't want to re-implement a database by
The same can be said with Fortran.
More information about the Haskell-Cafe