[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
tonyhannan2 at gmail.com
Thu Jan 8 19:21:22 EST 2009
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.
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 =
>> 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
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe