[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