> I didn't say yesod had the best website, I said they put the most effort into marketing. Michael and Greg do a lot of talking about yesod, and are the only haskell framework attempting to draw in people from outside of haskell. You seem to have interpreted this as an insult, it was not. Usage increases with awareness.
There was a heavy implication that they market at the expense of engineer.
> Unless you are using your RDBMS like a dumb storage system, then persistent doesn't provide the tools to access it. We're not talking advanced stuff here, the most basic fundamentals were done incorrectly: it requires int primary keys on all tables for crying out loud. Obviously multi-column foreign keys just went out the window then too. Of all our apps here, not even the most trivial could be ported to yesod using persistent.
Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier. If you're integrating an existing DB, yeah, it sucks. If starting from scratch, its pretty awesome. But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.
> Certainly. But the major difference between yesod and snap initially appears to be "yesod provides high level DB access and snap doesn't". This may be true of mongo DB (I have no use for it), but for an RDBMS it actually ends up being that neither provides high level DB access, and you have to use something from hackage.
[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe". The amount of errors we see in compiled Yesod code is shockingly minimal.
I am impressed at your ability to read that which I did not write. There was no such implication, it is a criticism of happstack and snap. More talking = more users = more feedback = better framework. It is especially unfortunate that snap originally seemed to be making serious efforts at marketing, and then just sort of stopped.
>Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier
We avoid the dumb storage model because it eliminates flexibility, and forces us to re-implement database functionality in our app code. We're talking about starting from scratch, I just don't want to start by throwing away all the power of our database for nothing. Our biggest apps are only in the 10s of millions of rows range, so scaling isn't a problem. If it were, I'd be looking into actual dumb storage systems though (mongo, cassandra, etc) instead of using an RDBMS as a slower version of one.
>But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.
Yes, but as I said that is the big feature that yesod appears to provide vs happstack and snap. But upon closer inspection we had to go down to hdbc regardless of the framework.
>[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe"
Citation for what? That if you don't use persistent then yesod and happstack and snap are similar in functionality? I am not sure how to prove that, how about the other way? What other functionality does yesod offer that I am forgetting?
Yesod avoids haskell in attempting to be "radically typesafe". You get the exact same amount of type safety by using blaze-html and web-routes in happstack or snap as you do using yesod. As I mentioned before, yesod's template haskell, quasi-quotation fetish is rather controversial in haskell land. You can get the benefits yesod offers while retaining composability and the familiarity of using haskell instead learning a DSL. The amount of errors we see in compiled haskell code is minimal, it should not be shocking that this extends to yesod.
I know there was talk of switching happstack over to warp, and then more recently of writing another server instead. What is it you are planning to do better than warp, performance, correctness, features or something I'm not thinking of? Is there anything in particular that made you decide not to use warp?
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 :)
> 2
Quite some research has been put in from the Yesod team on this matter. Michael Snoyman did not want to release Yesod 1.0 before the matter on pipes/conduits was settled.
> 3
This is because Yesod was not yet 1.0 -- the message was always that after 1.0 API breakage would only be allowed in major version jumps. (as it should)
> 4
Yups, everyone working on several big Haskell projects hopes this can soon be fixed. There's some GSoC proposal for it, I hope it gets through.
One question: would Happstack like to use Yesod's WAI? I see some progress has been made to that goal[1]. If you use WAI then your Warp competitor could also be used for Yesod.
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. :)
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.
http://www.happstack.com/C/ViewPage/5 http://www.happstack.com/C/ViewPage/7
- jeremy
(p.s. more meaningful urls are on the TODO list, but it was not critical enough to delay the launch of the new website).
This was fixed in the recent 0.8 release.
When we released to the public, Snap was the first serious high-performance Haskell web server based on left-fold enumerators to reach a usable level of maturity. We received an extremely positive reception documented both here and on reddit. That was two years ago. Fast forwarding to today, Happstack has made a lot of progress. Jeremy has done a fabulous job with the happstack tutorial. However it's still using the same lazy IO web server and still talking about changing. The API is still mostly the same except that the doc pages have been modularized in way that I find makes it harder to find what I'm looking for. I'd be tempted to say it's an objective criticism, but it could just be personal preference. It also looks like a significant amount of work has gone into web-routes and type-safe routing. This is usually marketed as being a Happstack thing, but as Jeremy recently demonstrated (https://github.com/stepcut/snap-web-routes-demo) it can easily be used in Snap apps.
During that time Snap has come a long way as well. We've ironed out a lot of bugs in the web server and associated API. A lot of thought has gone into preventing slowloris attacks, file upload vulnerabilities, and the like. We also have SSL support. Six months after we released Snap, Warp came onto the scene with better raw performance numbers, but it's not obvious to us that sacrificing the Snap web server's maturity for extra speed is in the best thing for our users.
On the high-level side, we've made great progress exploring the Heist templating paradigm. It has proven to be very flexible and have gotten a number of comments about how much users love it. You can also use Heist with Happstack, and similarly can use Snap with a different templating system. We spent at least 6-8 months designing our snaplet component system and feel that it turned out very well. Happstack doesn't have anything like this, and a number of the first things you'll likely need in building a web app on Happstack are already available on a modular basis as built-in or third-party snaplets. This is actually the heart of what we wanted to be working on when we started Snap, but we got side-tracked when we realized we weren't going to be able to use Hyena as our web server.
In summary, I would say that much of what is stated in the Happstack philosophy is also the Snap philosophy (the little False Simplicity jab at getParam has also been fixed). Moving to the five items in Happstack's roadmap, Snap already has points 2, 3, and 5 as well as some of the items in point #1. Even though it's not evident in Snap, I've always had a soft spot in my heart for acid-state, so I'm eagerly anticipating the planned replication and sharding. Snap already has an acid-state snaplet which means that it's probably easier to use acid-state in a Snap application than it is with Happstack. In my opinion, all this makes a compelling argument for Snap, but I'll echo Jeremy and conclude that if the Happstack project and community get you excited, then use Happstack. If you like what we're doing with Snap, then we'd love to have you using (and hopefully contributing to) Snap. Drop by the #snapframework IRC channel in Freenode. We're usually quite responsive.
I didn't say yesod had the best website, I said they put the most effort into marketing. Michael and Greg do a lot of talking about yesod, and are the only haskell framework attempting to draw in people from outside of haskell. You seem to have interpreted this as an insult, it was not. Usage increases with awareness.
>How so?
Unless you are using your RDBMS like a dumb storage system, then persistent doesn't provide the tools to access it. We're not talking advanced stuff here, the most basic fundamentals were done incorrectly: it requires int primary keys on all tables for crying out loud. Obviously multi-column foreign keys just went out the window then too. Of all our apps here, not even the most trivial could be ported to yesod using persistent.
>Any persistence layer you use with Snap or Happstack is just as easy to use in Yesod too.
Certainly. But the major difference between yesod and snap initially appears to be "yesod provides high level DB access and snap doesn't". This may be true of mongo DB (I have no use for it), but for an RDBMS it actually ends up being that neither provides high level DB access, and you have to use something from hackage.
>Again, how so?
Happstack's webserver has several issues, space usage being a major one. This isn't a controversial statement, Jeremy will tell you the same thing, it is why he's focusing on replacing happstack-server.