Tony Hannan ha scritto:

Let me give you more information about this hypothetical job posting. Our company is a startup CDN (http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years old and doing well. You would hythothetically be one of 7 programmer who write all the software involved in a CDN including http server, dns server, monitoring, load balancing, customer and operator user interface, etc. The pay depends on experience but is good.

Isn't it better to use Erlang for the http and dns server ? I don't really like the syntax, but you have many things already implemented. Unfortunately Haskell is not yet ready for this task. http://eddie.sourceforge.net/what.html http://yaws.hyber.org/

[...]

Regards Manlio Perillo

Achim Schneider ha scritto:

Manlio Perillo wrote:

...

Unfortunately Haskell is not yet ready for this task.

Could you -- or someone else -- please elaborate on this?

Here is a list of things that I would like to see in GHC to start developing a server application (in order of importance) 1) Support for scalable IO multiplexing. The GHC runtime only supports select. I find the ideas from the Unify paper interesting, however I don't really know if the implementation is "robust". I would also like to have epoll/kqueue support in single threaded applications 2) Convenient and flexible method for reading a stream of data. Lazy IO is not the answer. Iteratee seems interesting. 3) Support for process supervisor in the runtime. Of course I'm not interested in the Erlang supervisor system (spread over multiple machine), but I would like a simple master/slave system, like Nginx

[...]

Regards Manlio Perillo

Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice. Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it. Regards, John On Jan 8, 2009, at 4:10 AM, Achim Schneider wrote:

Manlio Perillo wrote:

...

Unfortunately Haskell is not yet ready for this task.

Could you -- or someone else -- please elaborate on this?

I've heard it once in the context of a webbrowser, the reason given was that ghc doesn't deallocate memory, that is, the gc heap only increases. I doubt it'd be hard to fix, not to mention that, iff a Haskell process is more or less the only process running on a system, deallocation becomes practically irrelevant... which'd be the case with e.g. a HAppS production server.

Any other known problems?

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Take, for example, RabbitMQ. There's nothing even remotely close in Haskell-land. RabbitMQ is written in 100% Erlang. It's built on Open Telecom Platform, which again is without equal in Haskell. There are a lot of theoretical reasons why Haskell would be a good choice to build libraries such as these, but lacking any production implementations, it's all just theory. Regards, John On Jan 8, 2009, at 8:41 AM, Creighton Hogg wrote:

On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote:

...

Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice.

Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it.

Now I understand that there aren't(?) any Haskell implementations that can act as distributed nodes the way the Erlang implementation can, but I'm not familiar enough with Erlang to understand what it has for networking that the Haskell network packages don't have. Could you explain a bit further? I've been thinking a lot about network programming anyway lately & am looking for library opportunities.

The number of applications requiring the implementation of a custom web server is an insignificant fraction of the number of applications requiring a messaging system. I don't think anyone would dispute Haskell's ability to do low-level, raw networking, of the type that few people actually need to do. It's the higher level stuff where there's a huge amount of room for improvement. Regards, John On Jan 8, 2009, at 10:31 AM, Tim Newsham wrote:

That would be useful for systems that require an "enterprise messaging system," I agree, but I don't see how that would be terribly important for a web server or most other networking services I might want to implement.

On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:

You replied to someone discussing using Haskell at a CDN to implement things like web servers by saying that Haskell wasn't suitable for the task.

That is incorrect. I replied to Achim's message asking for elaboration on Haskell's unsuitability. It was a convenient point to discuss Haskell's networking deficiencies. Regards, John

On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:

...

You replied to someone discussing using Haskell at a CDN to implement things like web servers by saying that Haskell wasn't suitable for the task.

That is incorrect. I replied to Achim's message asking for elaboration on Haskell's unsuitability. It was a convenient point to discuss Haskell's networking deficiencies.

Oops. My apologies.

Regards, John

Tim Newsham http://www.thenewsh.com/~newsham/

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

PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Perhaps this is another argument for my thread from a while back? http://www.nabble.com/Missing-Network-Functions-td21188779.html

/jve On Thu, Jan 8, 2009 at 4:37 PM, Bardur Arantsson wrote:

Manlio Perillo wrote:

...

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.

[--snip--]

Indeed. I've been looking for a Haskell HTTP server implementation that can actually handle file serving using strictly limited memory (for a simple UPnP server, as of yet unreleased) and that also doesn't leak handles like a sieve, but I haven't found anything yet. I don't know, maybe my hackage-foo is lacking. In the end I just rolled my own implementation using the HTTP package for parsing requests and doing all the socket I/O myself using low-level primitives. It seemed to be the only way to guarantee reasonable resource usage while serving multi-gigabyte files to fickle HTTP clients that like to drop connections willy-nilly.

Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton).

Oleg's Iteratee does look very interesting though. Maybe I'll have a go at trying to use his ideas in my UPnP server.

Cheers,

Bardur Arantsson

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

John Goerzen wrote:

On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote:

...

Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton).

Look at Haddock for PortNumber:

newtype PortNumber Constructors PortNum Word16

Instances

Enum PortNumber Eq PortNumber Integral PortNumber Num PortNumber Ord PortNumber Real PortNumber Show PortNumber Typeable PortNumber Storable PortNumber

Try it in ghci:

Prelude Network.Socket> 15 :: PortNumber 15 Prelude Network.Socket> PortNum 15 3840 Prelude Network.Socket> (fromIntegral (15::Int))::PortNumber 15

So, in essence, there are *many* functions that let you do this. You should not be needing to construct PortNum by hand.

Thanks. For some reason I hadn't thought to use (fromIntegral x)::PortNumber I guess I got stuck on the idea of constructing a PortNum directly and didn't think beyond that. (Maybe PortNum should really be an abstract type to force indirect construction...?) I guess the API isn't all that idiosyncratic after all :). Cheers, Bardur Arantsson

Bardur Arantsson wrote:

Thanks. For some reason I hadn't thought to use

(fromIntegral x)::PortNumber

I guess I got stuck on the idea of constructing a PortNum directly and didn't think beyond that. (Maybe PortNum should really be an abstract

No problem. I knew exactly what your problem was because I had the exact same blinders on when I first learned the Haskell networking API. It would be helpful to have a pointer to this in the Haddock docs, because it is non-intuitive to somebody just learning it.

I guess the API isn't all that idiosyncratic after all :).

Just a touch under-documented ;-)

On 2009 Jan 9, at 20:51, Tim Newsham wrote:

I'm suprised htonl comes up so often. You can unmarshall data directly from a byte stream to an Int type without caring about the underlying representation of your Int. Why do people want the htonl function?

IP address math. (see @ipcalc in #lopsa's lambdabot) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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

On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

So, if I need to write *now* a network application, should I *invest* in Haskell, or should I just *use* Erlang?

You're in Haskell-Cafe... the bias is there already for Haskell. Personally, I don't have experience doing network applications in Haskell, but I've got about a year's worth or more using Erlang, so for me it's a pretty easy choice, and I wouldn't pick Haskell today. (hearing boos in the background as I type this...) However, I would invest in learning to use Haskell, because my experience with Erlang has been that it really is pretty great, and has lovely features, like the ability to shell into a running process and poke around if something seems not quite right, or even to ssh into it if you run the right services. Plus there's tons of stuff pre-written for network applications that just comes with the Erlang distribution, meaning there's nothing else to install.... but even after all of that, I miss the type safety of Haskell, as it's really painful to do this in erlang function(T1, T2, T3) when is_list(T1) and is_integer(T2) and is_integer(T3) -> ....function body Even if you have a list, you don't know "what of" so you never really get the guarantees that you get when a Haskell program successfully compiles... That peace of mind is not easily won in Erlang, except by lots of testing. Dave

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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

John Goerzen wrote:

On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:

...

The number of applications requiring the implementation of a custom web server is an insignificant fraction of the number of applications requiring a messaging system. I don't think anyone would dispute Haskell's ability to do low-level, raw networking, of the type that few people actually need to do. It's the higher level stuff where there's a huge amount of room for improvement.

I disagree on both points.

Haskell has had somewhat of a deficit in the low-level networking stuff, not even supporting IPv6 in the standard stack until just recently. (That is, things like AF_INET6 were not present.)

I think it has pretty much caught up by now though.

Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, receive the replies.)

Not all the data structures you need are there last I looked. As you could infer from my recent posts, one of my dozen future projects is to add netinet/*.h like data structures to the Haskell network library (i.e. TCP, IPv4, UDP headers with Binary instances). This isn't to say your task would be much more difficult, but it would be nice to have a community wide definition available. Tom On Thu, Jan 8, 2009 at 10:50 PM, John Goerzen wrote:

Andrew Coppin wrote:

...

John Goerzen wrote:

...

On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:

...

The number of applications requiring the implementation of a custom web server is an insignificant fraction of the number of applications requiring a messaging system. I don't think anyone would dispute Haskell's ability to do low-level, raw networking, of the type that few people actually need to do. It's the higher level stuff where there's a huge amount of room for improvement.

I disagree on both points.

Haskell has had somewhat of a deficit in the low-level networking stuff, not even supporting IPv6 in the standard stack until just recently. (That is, things like AF_INET6 were not present.)

I think it has pretty much caught up by now though.

Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, receive the replies.)

SocketType claims to support Raw, which I think is the conventional means for doing this. Whether all the infrastructure for that is there, I don't know. I have never worked with raw sockets though, so I may be leading you down a dark mugger-laden alley here ;-)

-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I've managed to get UDP NAT traversal working in my personal project. I haven't really had issues with the Networking libraries at all (except that htons and htonl aren't where i expected them to be... and yes, i did actually need them...) /jve On Fri, Jan 9, 2009 at 1:18 PM, Andrew Coppin wrote:

Thomas DuBuisson wrote:

...

Not all the data structures you need are there last I looked.

This was my conclusion as well.

As with most network libraries I've seen, TCP works just great, and anything else... tough? (I couldn't even see UDP last time. Have I missed something?)

As you

...

could infer from my recent posts, one of my dozen future projects is to add netinet/*.h like data structures to the Haskell network library (i.e. TCP, IPv4, UDP headers with Binary instances). This isn't to say your task would be much more difficult, but it would be nice to have a community wide definition available.

That would, indeed, be nice.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Dominic Steinitz wrote:

John Goerzen writes:

...

...

Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, receive the replies.)

SocketType claims to support Raw, which I think is the conventional means for doing this. Whether all the infrastructure for that is there, I don't know. I have never worked with raw sockets though, so I may be leading you down a dark mugger-laden alley here

Here's an example of a Haskell version of ping, now sadly bit-rotted.

Dominic.

http://haskell.org/networktools/src/ping/test.hs

I have a worrying feeling this might be too Unix-specific to work on Windows. But I guess it's a start...

wchogg:

On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote:

...

Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice.

Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it.

Now I understand that there aren't(?) any Haskell implementations that can act as distributed nodes the way the Erlang implementation can, but I'm not familiar enough with Erlang to understand what it has for networking that the Haskell network packages don't have. Could you explain a bit further? I've been thinking a lot about network programming anyway lately & am looking for library opportunities.

Note that there even exists an FFI binding to Erlang for Haskell, so that Haskell nodes can seamlessly interact with other nodes speaking Erlang's protocol format. There's nothing stopping you using Haskell nodes in a distributed fashion, and indeed there are groups doing this. -- Don

John A. De Goes wrote:

Here's hoping someone develops a native messaging framework for Haskell, which is the equal of RabbitMQ.

The first thing would be to make a Haskell client library to speak AMQP (Advanced Message Queuing Protocol) on the wire. It is a very open binary standard (with defined semantics!) at http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protoc... I would be mildly surprised if zero people were working on this. Once that is in place then the question of a Haskell Broker for AMQP arises. But I suspect that Erlang's runtime will still rule there for "production use". -- Chris

On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote:

...

But really, what's the point? FFI code is fragile, often uncompilable and unsupported, and doesn't observe the idioms of Haskell nor take advantage of its powerful language features. Rather than coding through

Just for clarity's sake, we should specify that the Erlang ffi interface that's been worked on (not my project, I've just browsed the code) is *not* low-level via C, but rather a set of parsers/ unparsers between haskell data types and the Erlang wire format and a set of behaviors for message queuing that between them let a haskell program act as a node to Erlang programs, or let Haskell programs communicate between themselves as nodes, which just coincidentally happen to use the same wire format as Erlang. Which is not to say that Erlang does not have specific excellent libraries that allow *certain types* of network programming do be done very easily. The Haskell library-space has lots of room to grow, and lots of inspiration to take from the OTP (although less for "hot-swapping" which is somewhat overrated, and more from supervision-tree type stuff). However, even now an adequate subset of whatever functionality is needed can be whipped up pretty quickly for any project requiring only that subset. Cheers, S.

On Thu, Jan 8, 2009 at 12:06 PM, Don Stewart wrote:

wchogg:

...

On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote:

...

Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice.

Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it.

Now I understand that there aren't(?) any Haskell implementations that can act as distributed nodes the way the Erlang implementation can <snip> There's nothing stopping you using Haskell nodes in a distributed fashion, and indeed there are groups doing this.

Didn't realize it was charted territory. Sorry about that.

You must be referring to "erlang-0.1", an alpha release of a package that impersonates an Erlang node. Which is surely useful to someone, somewhere, but is not useful to write a messaging application. Regards, John On Jan 8, 2009, at 4:17 PM, Bryan O'Sullivan wrote:

On Thu, Jan 8, 2009 at 10:06 AM, Don Stewart wrote: Note that there even exists an FFI binding to Erlang for Haskell, so that Haskell nodes can seamlessly interact with other nodes speaking Erlang's protocol format.

Actually, the erlang package doesn't use the FFI: it speaks the Erlang wire protocol to send and receive terms. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

manlio_perillo:

Tony Hannan ha scritto:

...

Let me give you more information about this hypothetical job posting. Our company is a startup CDN (http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years old and doing well. You would hythothetically be one of 7 programmer who write all the software involved in a CDN including http server, dns server, monitoring, load balancing, customer and operator user interface, etc. The pay depends on experience but is good.

Isn't it better to use Erlang for the http and dns server ?

I don't really like the syntax, but you have many things already implemented. Unfortunately Haskell is not yet ready for this task.

http://eddie.sourceforge.net/what.html http://yaws.hyber.org/

Umm... http and dns? You're kidding right? Half of hackage.haskell.org is devoted to networking tasks. -- Don

On Thu, 8 Jan 2009, Manlio Perillo wrote:

Personally, I only know http://hpaste.org/, based on Server: HAppS/0.8.4

I'm using a modified HWS for the parallel webs, e.g. the Real Monad Transformer: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category... However, recently a lot of accesses made the server quite unusable.

John Goerzen wrote:

On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote:

...

I'm speaking about servers, not clients.

...

Personally, I only know http://hpaste.org/, based on Server: HAppS/0.8.4

Take a look at Hackage. There are quite a few other Haskell web frameworks as well: everything from the low-level FastCGI to higher-level HSP and WASH.

FastCGI is not a HTTP server. WASH seems so include one, but the latest version ("Wash and go") seems to be from mid-2007 ("tested with GHC 6.6" as the web page states), unless of course I'm looking at the wrong page. That doesn't exactly inspire a lot of confidence. Now, if you're talking about using, say, Apache + FastCGI then you'll probably have something pretty robust, but I don't think that counts as a "Haskell server". Generally my experience has been that most of the Haskell server stuff hasn't been very mature.

...

And about HAppS, I'm not an Haskell expert, but reading the source I see that static files are server (in the HTTP server) using Data.ByteString.Lazy's hGetContents

Is this ok?

In what respect? The fact that something uses ByteString.Lazy.hGetContents doesn't imply a problem to me. It's a useful function. It can be used properly, or not, just as while or read() in C can be.

It's a great way to introduce unavoidable handle leaks, that's for sure. Cheers, Bardur Arantsson

On Fri, Jan 09, 2009 at 01:06:44PM +0100, Manlio Perillo wrote:

John Goerzen ha scritto:

...

On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote:

...

I'm speaking about servers, not clients.

How much of pure Haskell internet servers are used in a production environment, in the "open internet" (and not in restricted LANs)?

Does that really matter? I tend to judge technology based on its merits for my work, not on who uses it.

Well, testing a server is not easy. You can have a server that works for you without problems, but in different environment it gives problems.

I completely understand that, as a sysadmin that has to maintain mission-critical systems. Unfortunately, it's also so often used as a justification for using "whatever everyone else has". So many people buy Exchange for that reason, as an example. Exchange has a pretty long history of bugs that make it really unsuitable for use in the Enterprise, yet people use it anyway because they think everyone uses it. A particularly amusing example is at http://software.complete.org/software/issues/show/114 - my little OfflineIMAP program appears to be able to take down entire Exchange databases and force a restore from backup, because Exchange has a hard-coded limit of 32k different mail header names *per installation*, and OfflineIMAP generates one unique header each time it uploads a message to the server. If my program can do that accidentally, imagine what someone with a will to do that could do. Nobody would have ever tried Haskell, Python, or Perl in mission-critical situations if they always thought like that. Somebody has to be first, and I see no problem with it being us, as long as we are confident of the outcome. Part of the calculus has to be: 1) Can we test it under stress? 2) How confident are we that it will behave right under conditions we can't test? (Esp. malicious ones) 3) Can we fix it ourselves if it breaks? How many others can fix it? I really like Haskell because of #2. While there is no 100% guarantee, I feel better about Haskell not throwing a type error in some obscure condition than I do about Python not doing so. I also like #2 because of the availability of both HUnit and QuickCheck. Write your code right, and you can QuickCheck a significant part of it. -- John