For me, the biggest downside is lack of solid embedded device support -- arduino (Atmel AVR), android(ARM), iOS (ARM).
After using Haskell pretty much full-time for 10 years, writing C and Java code makes me sad. The support for the above mentioned platforms is in-progress, but is not yet mature.
There are some neat things like Atom which use a Haskell DSL to target arduino.
My other issue is that the garbage collector in GHC is not really sufficient for real-time audio applications because it can pause for too long. GHC HQ has tried to tackle this in the past -- but there is a reason why it is a research topic :)
If your application requires interfacing to a C++ world -- your are not going to have fun. Though there might be a GSoC project for that this summer?
Also, GUI stuff is somewhat lackluster. There are bindings to gtk, etc. And they can get the job done. But they don't really capture the essence of what makes Haskell awesome. We are still searching for the GUI abstraction that really clicks.
Well, there is no bad choice when it comes to picking a Haskell web framework. They are more alike than they are different. Anything you could develop in one, you could develop in another. There are certainly no magic bullets in any of the frameworks.
There are certainly many minor design decisions that you can compare. For example, last time I looked at Snap, it seemed like variables captured from the url, got mixed into the same environment as key/value pairs from the QUERY_STRING and POST data. And, they explicitly decided to provide only a Snap monad, but not a SnapT monad transformer. But, none of those are, in themselves, things that warrant switching.
You could also consider which technologies the frameworks embrace, such as Heist vs HSX. At the same time, heist is officially supported by happstack (and even documented in the crash course). A lot of the core technology like acid-state, heist, hsx, jmacro, persistent, etc, can be used with any of the frameworks.
It mostly comes down to picking the framework that is investing the future you think is most exciting.
So, if the Happstack Philosophy and Roadmap get you excited, then use Happstack. If you think Snap's vision of tomorrow is more exciting -- then use Snap.
I think you mean, "Snap is pretty much the same as Happstack", since Happstack came first, and Snap borrowed many ideas from it.
I would tell Snap users they should use Happstack because we have a shiny 3D graphic on our homepage. That is based on my in-depth research which indicates that many people decided to use Snap because it had the prettiest homepage. :)
I think that as far as the end user is concerned, there is not much difference between the warp, Snap, and Happstack backends.
Speed-wise, warp is maybe 3 times faster than Snap and Happstack in the pong test. Though, how that plays out in real world is hard to say. But, I doubt anyone is running a Haskell web server right now that needs anywhere close to 30,000+ requests/second. Of course, speed never hurts. Even if you are not doing a lot of requests per second, the totally latency per request counts for something. So, I see no reason for Happstack to be slower than it could be.
Because Happstack is based on lazy IO instead of conduits/enumerators/pipes, there is a perception that it must be leak files and RAM like crazy. But, that is not actually true. The server handles streaming files from disk fine, and even streaming files in POST/PUT to disk in a constant space. We had to be careful inside the server code to make that happen -- but the end user never has to deal with that for the most part.
One exception is when the user wants to use IO to generate a streaming response. For example, if you were wrote an algorithmic music generator that required IO and streaming an never ending MP3. To do that in happstack-server, you could need to use unsafeInterleaveIO. And, be a bit careful.
But, just because lazy IO can work, doesn't mean that something like Pipes would not be better. Happstack predates enumerators/pipes/conduits, so lazy IO was the best choice at the time :) The idea of moving Happstack away from lazy IO has been an the plate for a long time (before Snap and Yesod were even created). Originally we were going to move to the hyena backend. But then Johan went on a major yak shaving expedition and rewrote the GHC I/O manager, etc, instead of finishing hyena.
We did consider switching to warp. But there are a few reasons we decided not to:
1. The source code for warp did not fill me with confidence (yes.. entirely subjective). So, in the new (currently unnamed) happstack-server backend (which will be standalone similar to warp), I want to create a strong body of evidence that it actually works correctly.
2. I like pipes. At least, I like the way they are designed by starting with the core principles and semantics and trying to build something up that is based around solid math foundation like Category. Now, Michael Snoyman may be correct that pipes are not suitable for implementing an http proxy. Once the next pipes (that has resource finalization and exception handling) is out, I intend to discover if that is true or not (acme-http-proxy). (Once again, very subjective).
3. I want Happstack to be a stable platform. Historically, yesod has gone through a lot of radical changes. Something is there one day, and gone the next. My previous experiences trying to collaborate directly and indirectly with the yesod team have left me nervous about building on their work. The yesod project is focused on what is best for their own purposes -- which is fine. But, it means that if you are trying to build on it, you have to be ready to accept whatever may drop out of the sky tomorrow morning. (Also subjective).
4. the yesod dependency hell problem gives me concern as well. While the problems they are experiencing are fundamental to Cabal itself, they seem to be hit a lot harder than Happstack. So, until that is all sorted out, I don't want to make Happstack installs more likely to fail.
Given that warp is less than 1000 lines, it seems like the risks and loss of control involved with trying to leverage it do not really outweigh the cost of implementing a solution that is exactly what we want.
So, I am aiming for better design, performance, and correctness.
In terms of features.. I'm saving that surprise for later :)
I am Jeremy.. and I am not sure I would tell you the same thing. The Happstack webserver is pretty darn good. Of course, I think we can do even better. In fact, I think we can do better than warp.
acid-state, http://acid-state.seize.it/, which was previously known as happstack-state, and before that HAppS-State, has been doing it since 2005 or so.
acid-state currently lacks replication/multimaster support, but happstack-state has had several experimental implementations of that as well.
acid-state is Haskell specific.. but that is part of the appeal. You can directly store fancy algebraic data structures with acid-state. You are not limited to a simple combination of records integers and strings (for example).
After using Haskell pretty much full-time for 10 years, writing C and Java code makes me sad. The support for the above mentioned platforms is in-progress, but is not yet mature.
There are some neat things like Atom which use a Haskell DSL to target arduino.
My other issue is that the garbage collector in GHC is not really sufficient for real-time audio applications because it can pause for too long. GHC HQ has tried to tackle this in the past -- but there is a reason why it is a research topic :)
If your application requires interfacing to a C++ world -- your are not going to have fun. Though there might be a GSoC project for that this summer?
Also, GUI stuff is somewhat lackluster. There are bindings to gtk, etc. And they can get the job done. But they don't really capture the essence of what makes Haskell awesome. We are still searching for the GUI abstraction that really clicks.