Yes, reasoning about laziness and difficulties using types are library issues.
I disagree, if the language were strict by default, this was not an issue. It is a language problem that is forced on libraries.
However, for most Ruby web applications that I have worked on I have had to spend time re-writing slow parts of the application because Ruby was truly the bottleneck,
My point was that Haskell is often a lot slower than C of C++, so people will rewrite CPU-intensive code anyway. Look at many of the popular Haskell modules where heavy-lifting is done (from compression to encryption), most of them are C bindings. That code will be nearly equally fast in Haskell as in, say Python.
BTW. I am not arguing that Haskell not faster than Python, Ruby, Clojure, etc. But for computationally intensive work C/C++ are still the benchmark, and that is what people will use in optimized code. Whether it is Haskell or Python.
Particularly if a library is forcing you to learn about existential types.
But why is it? Because the language does not support the kind of polymorphism that is commonly used, in an intuitive fashion. People need containers with mixed types that adhere to an interface in some applications. And a commonly-used method to realize this in Haskell is by using existential types.
we can at least agree that async IO is a big win
Yes.
And likewise deployment to multi-core is no extra effort in Haskell/Erlang, whereas in Node, Ruby, or Python you will need to load balance across multiple processes that are using more RAM.
Since most modern Unix implementations do COW for memory pages in the child of process of a fork, this is not so much of an issue as people make it out to be. The fact that you mention Erlang is curious, since spawn in Erlang forks a process, right? Forking is more expensive than threading, but again, in most applications negligible compared to handling of the request.
The biggest reason why there are Haskell packages wrapping C libraries is not for performance, but to reuse good C libraries, and because Haskell has an excellent interface for C libraries. Many people prefer to write Haskell for computationally intensive tasks than C/C++. Depending on the problem it is possible to get within 2x the raw speed of C and you much nicer code to maintain and much easier concurrency/parallelism opportunities.
I have not found it to be the case that existential types are commonly needed (and need to be forced on the user). Maybe you are in a different problem domain. I find Haskell's regular polymorphism to work very well for 95+% of my use cases.
Fork is not negligible to handling a request, but pre-forking theoretically could be. In practice, COW fork does not automatically solve multi-core. The Ruby garbage collector is not COW friendly and thus there is little memory savings from COW (unless you use the REE interpreter which has a slower COW friendly garbage collector but saves on memory and GC time). I haven't looked at this for other languages but I assume this is still a limiting issue. Also, you are still stuck doing load-balancing between your processes, which will limit or complicate your deployment. I don't know much about Erlang other than async IO is built into the language, which is why I mention it in the same breath as Haskell.
In case anybody is wondering: both Erlang and Haskell have very lightweight user-space threads built in, which are mapped onto a small pool of OS threads to take advantage of however many cores you have. It's very slick and fast, and probably the Right Thing.
Yes, there's also akka which is being incorporated as scala standard lib, and F# MailboxProcessor. The thing is that erlang/OTP and its behaviors have many people pounding on heavily loaded apps in production and improving its toolchain, whereas GHC and akka have recently (last couple years I think) been working ot get the stack working: dispatchers and load balancing (like erland reds), and bring GC up to snuff
Akka looks pretty sweet, but it looks like you still have to worry about blocking code in external libraries. In Haskell (and Erlang, IIRC), blocking code is deferred to a background thread automatically so you don't have to be consciously on-guard for it. You also get proper pre-emptive multithreading, while Akka looks like a hybrid of an event loop and a thread pool.
Is this a substantial headache with Akka, in practice?
I disagree, if the language were strict by default, this was not an issue. It is a language problem that is forced on libraries.
However, for most Ruby web applications that I have worked on I have had to spend time re-writing slow parts of the application because Ruby was truly the bottleneck,
My point was that Haskell is often a lot slower than C of C++, so people will rewrite CPU-intensive code anyway. Look at many of the popular Haskell modules where heavy-lifting is done (from compression to encryption), most of them are C bindings. That code will be nearly equally fast in Haskell as in, say Python.
BTW. I am not arguing that Haskell not faster than Python, Ruby, Clojure, etc. But for computationally intensive work C/C++ are still the benchmark, and that is what people will use in optimized code. Whether it is Haskell or Python.
Particularly if a library is forcing you to learn about existential types.
But why is it? Because the language does not support the kind of polymorphism that is commonly used, in an intuitive fashion. People need containers with mixed types that adhere to an interface in some applications. And a commonly-used method to realize this in Haskell is by using existential types.
we can at least agree that async IO is a big win
Yes.
And likewise deployment to multi-core is no extra effort in Haskell/Erlang, whereas in Node, Ruby, or Python you will need to load balance across multiple processes that are using more RAM.
Since most modern Unix implementations do COW for memory pages in the child of process of a fork, this is not so much of an issue as people make it out to be. The fact that you mention Erlang is curious, since spawn in Erlang forks a process, right? Forking is more expensive than threading, but again, in most applications negligible compared to handling of the request.