[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

[Manlio Perillo]

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 =
>        do
>        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
    current positions
2) file buffer, where you have a file descriptor and the current file
    offset

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 
myself.
The same can be said with Fortran.

 > [...]


Regards   Manlio