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

[Tony Hannan]

That's great to hear Bryan. I look forward to all of your projects you just
mentioned, and work from others like you said, so one day soon we can built
really high-performance web servers in elegant Haskell code.

I also like Reactive (or FRP in general) as a declarative alternative to
message passing, and hope it will be high-performance as well.

Cheers,
Tony

2009/1/8 Bryan O'Sullivan <bos at serpentine.com>

> On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <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.
>    - 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'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.
>
> 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.
>
> I actually think that we're very close to being in fantastic shape here.
> I'm working on a memcached client library that uses the above libraries, and
> it's faster than the absolute best C memcached client (libmemcached), while
> also far smaller and elegantly layered. As a community, we are developing
> many proofs that you can have beautiful code without sacrificing
> performance.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/5e77b1f1/attachment.htm