You're right, it doesn't matter too much what language you do a piece of software in, it's more the design. BUT! When the language tries to make sockets way more complicated than needed, screws with memory management to the point of uselessness, or cram its little version of "stateless" false dogma down your throat, it sure doesn't make it easy.
Alright then, if you'd do it in Haskell, why haven't you? I spent about 2-3 weeks so far on Mongrel2 and it already does quite a lot. I figure, hey, Haskell's supposedly so much more bad ass, let's see you get it done. In fact, I'll be you don't even use any of these Haskell web servers as your main web server:
Thus my point. Language fetishists become distracted by the hype and dogma of their favorite language tribe and then become blind to the evidence. Evidence so far says C makes good web servers. Web servers in other languages tend to need to use C. Lots of great software powers the world and is written in C. Using C does not cause the death of the universe. It isn't hard, or scary, it's actually pretty simple.
After a while, you have to start wondering, is it true that the language is so dangerous, or is it just more marketing?
It's not more marketing, Zed, it's years and years and years of evidence that poorly-managed memory is a major source of error in design, and folks in the application development and security fields trying to pass along a message to avoid it if possible. State is also a major source of error in design, which is why stateless dogmatists keep hammering on it. You can get good design without them, and some people do. But everyone makes mistakes sometimes. Picking technologies that help you avoid making them isn't marketing, it's just good sense.
People have a bad habit of calling any received wisdom they disagree with "marketing". There are people out there far smarter than I am, and possibly smarter than you are (though I'm not in a position to judge), who disagree strongly with what you say, and they're not marketeers. No need to go down that route in this debate.
Bad programmers are the cause of everything you said, not the tools they use. For example, if you compile a language to machine code and use a linker, then I can inject memory errors and violate your view of state. Unless you have link time assertions, your carefully crafted "safe state free" languages aren't.
"State is also a major source of error" is an unsupported claim. Show me any usability study that confirms removing state improves a programmer's source and understanding of the solution.
The truth is, all of the concepts of state free, type systems, assertions, and design by contract are just specific limited cases of a more flexible assertion system. Type systems are a compile time assertion that you are getting a type you expect. Design By Contract are runtime assertions about state of the system. So is assert in C. Removal of state like in Haskell is just a very restrictive design by contract alternative compile time assertion.
If all of these are specific cases of a general assertion system, then none of them cover the complete set of assertions you'd need to truly make "safer" software. You'd need link time assertions (dll hashes and version required, function prototypes required), compile time assertions more flexible than types, and runtime assertions like design by contract.
Unless your language has all of those in an optional way (which would be a pain in the ass to use) then your language is truly no better than C.
I agree that not all of the things you list necessarily reduce errors, or that those that do increase productivity over the long run, because you sort of straw-manned me a little bit there. Me, I don't love strong type systems. But garbage collection doesn't fall into that category.
As for state, the concerns there are confined primarily to concurrent systems, and about a gazillion people have discussed its problems with greater eloquence than I can muster (Joshua Bloch comes to mind). But you're a great programmer--no sarcasm intended--and if you say you can produce a great concurrent system and still carry around a ton of state then I believe you. I'm genuinely looking forward to the fruits of your labor. Most people, myself included, can't.
The goal isn't to twist yourself or your users into a pretzel trying to build a language that prevents any error whatsoever from occurring, as far as I'm concerned. The goal is to produce a language that shrinks the potential for bad stuff on the downside and encourages good practices (and stays out of your way) on the upside. C did, in its day, accomplish both things admirably, and for some tasks it remains the best tool. It does not, however, follow that all of its shortcomings are in fact virtues, and that those who say otherwise are marketing.
I'll give you a hint about how it's done: Finite State Machines. They're provable, simple, and are designed to handle state. Removing state isn't the answer. Giving programmers great FSM tools is (like in Erlang).
You are confusing mutable state and state. Of course you need state. What you don't need is randomly overwriting blocks of memory when your program makes a state transition.
Instead, you want more structured state transitions. A FSM is one way of getting that.
Not really a fair comparison. From 1972 until 2000, C was the most performance/expression balance that industry could bear. Lisp sacrificed raw computational performance for increased readability and writability, but that's a tradeoff that was unpopular in industry. Hence, it was never a viable competitor. (I like it, but I am not industry.)
A fair comparison is C to C++ or Java to C#. C has been around longer than C++, and there are more C apps than C++ apps on UNIX. (Windows is another story; MS pushed C++ pretty hard back in the day. Same for Obj-C on Mac.)
Java has been around longer than C#, and there is more stuff written in it, even though it is technically inferior. Time always beats language features.
If you want an accurate measurement, start a totally new project today that depends on nothing. Clone yourself. Then start writing it in C, and in $some_other_language. Then see which one meets your expectations soonest. It will probably be $some_other_language. But add in some dependencies on historical code, and C becomes competitive again.
Standing on the shoulders of a giant is faster, in the short term, than becoming a taller giant.
I suspect that technical matters such as deployment and integration with other components is of greater concern (though I also suspect that the kind of language fetishism which looks balefully on the use of anything other than C as a system programming language has some effect).
Honestly, it comes down to other languages not understanding how sockets, pointers, and memory really work. When you do servers like this, that's all you're dealing with (plus parsing). In other languages they try to hide these things away from you, or just screw up the concepts making them no easier to use.
For example, if you want to parse an HTTP header in Python you have to iterate through either integers, or break it up into smaller strings, or use the really bad tokenizer library. Most languages with immutable strings make fast parsing and "copy on write" semantics difficult, so they're already harder to work with.
Another example is how they screw up sockets. In C sockets are simple, requiring only a few function calls to work with, and then a bunch of error conditions. Everything you get out of them is bytes put into a buffer of your choice. In other languages you have to work with some badly designed OOP layer that makes no sense, exception classes for each errno, randomly sized buffers with no Chord data structure, or an event system like Twisted that gives no ring buffer or state machine functionality.
In the end, implementing the solid core of a web server is just easier in C. I wouldn't want to implement a full blow web app in it, because doing something like a template system is murder (dynamic languages win hands down there). But the core is much easier.
While in general your criticism of network libraries is generally sound, I believe Haskell gives you more or less the same API as C sockets if you want it.
Alright then, if you'd do it in Haskell, why haven't you? I spent about 2-3 weeks so far on Mongrel2 and it already does quite a lot. I figure, hey, Haskell's supposedly so much more bad ass, let's see you get it done. In fact, I'll be you don't even use any of these Haskell web servers as your main web server:
http://www.haskell.org/haskellwiki/Haskell_Web_Server
Thus my point. Language fetishists become distracted by the hype and dogma of their favorite language tribe and then become blind to the evidence. Evidence so far says C makes good web servers. Web servers in other languages tend to need to use C. Lots of great software powers the world and is written in C. Using C does not cause the death of the universe. It isn't hard, or scary, it's actually pretty simple.
After a while, you have to start wondering, is it true that the language is so dangerous, or is it just more marketing?