[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
Manlio Perillo
manlio_perillo at libero.it
Thu Jan 8 16:07:37 EST 2009
John Goerzen ha scritto:
> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
> [...]
>
> On the other hand, I see nothing in Haskell that would prevent its use
> for any of your purposes. There are numerous high-level web
> infrastructures already. Perhaps they are more or less suited to your
> needs, but that's a library issue, not a language issue.
The question is not about Haskell language.
I think that Haskell is far better than Erlang, and in fact I'm studying
Haskell and not Erlang; and one of the reason I choosed Haskell is for
its support to concurrency.
The problem, IMHO, is with the availability of solid, production ready
servers implemented in Haskell, that can be used as case study.
The major web framework in Haskell is HAppS, if I'm correct, and yet in
the HAppS code I see some things that make me worry about the robustess
of the code.
I you grep for hGetsContent, it appears in place where I'm not sure if
it is safe to use.
One example is in serving static files.
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
Now, if you read the paper about iteratee:
http://okmij.org/ftp/Haskell/Iteratee/
you should have doubts about how robust all of this is.
The other problem is with the use of select in the GHC runtime for IO
multiplexing.
I know that things works, but using select in a server that should
support many concurrent requests, is not really what you really want.
Regards Manlio Perillo
More information about the Haskell-Cafe
mailing list