Live data from Hacker News

Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

yesodweb.com

81–90 of 113 posts

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#81

Earlier quoted context omitted.

I'm aware of the benefits of using cookies for session state, just not sure encryption itself offers serious benefits without encrypting the entire browser session via SSL. And it may offer disadvantages from an understanding standpoint, where people think the encrypted cookie provides more security than it actually does.

If properly encrypted with an authenticated encryption mechanism then the server can be sure that the data has not been modified and has not been read. This would allow private data to be stored. As long as the server is the only one that knows the key, then only the server can read it. An evesdropper can still use the cookies for replay attacks, but at that point they're on the connection already. It's useful for th…

(1) Modification-prevention (the changing your account to someone else's by modifying the user id situation) is provided by the HMAC, not encryption. This is why Rails session cookies are not encrypted (as far as I know), for example.

(2) If someone has your cookie, they're either already on your connection or they're on your computer.

(3) The only situation where this provides any security is one in which you store data in the cookie that would not be accessible to the same user through the site. I can't think of any such data in any of my experience, but I will absolutely grant that such data may exist.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#82

Earlier quoted context omitted.

If properly encrypted with an authenticated encryption mechanism then the server can be sure that the data has not been modified and has not been read. This would allow private data to be stored. As long as the server is the only one that knows the key, then only the server can read it. An evesdropper can still use the cookies for replay attacks, but at that point they're on the connection already. It's useful for th…

(1) Modification-prevention (the changing your account to someone else's by modifying the user id situation) is provided by the HMAC, not encryption. This is why Rails session cookies are not encrypted (as far as I know), for example. (2) If someone has your cookie, they're either already on your connection or they're on your computer. (3) The only situation where this provides any security is one in which you store…

(1) Well, he said

> If properly encrypted with an authenticated encryption mechanism

(2) Being on one's connection is the default assumption of the internet security model.

(3) Right, the confidentiality of the site's data from the site's user may not be critical. But if done properly it does allow the site to ensure that the data it stored has not been tampered with (except perhaps to drop it or replay it). Surely this can be useful.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#84
post #77

Earlier quoted context omitted.

> Personally, I can't stand [...] I also hated [...] it drove me nuts [...] I found it was just as ugly [...] https://www.google.nl/search?&q=haters-gonna-hate&tb... As explained before in this thread "shakespear-text" is the plain-ERB of Yesod. To unmix code and markup i'd advise simply use you discipline; it's far to handy to use it sparingly but avoid it otherwise. (But that's my opinion) I think your contribution…

http://ycombinator.com/newswelcome.html This isn't reddit, please spare us the memes and +1s. I think the odds of such a contribution being well received are quite low given the hostility to that notion the developers of yesod still display. Given that I can't see any benefit to using yesod, it seems like a waste of time for me to contribute an unwanted template engine to it.

> This isn't reddit, please spare us the memes and +1s.

Ok. Yr right, point taken.

> I think the odds of such a contribution being well received are quite low given the hostility to that notion the developers of yesod still display.

Hostility I've never encountered. I think the Yesod is super welcoming contribs (the recent discussion on pipes/conduits being a great example of that).

> Given that I can't see any benefit to using yesod, it seems like a waste of time for me to contribute an unwanted template engine to it.

Do you mean "can't see any benefit to using yesod" over using Snap? Because I see quite a bunch of benefits in that comparison. Let me name the ones I perceive as benefits:

* More type-safe

* Write less code to get it done (using template haskell and quasiquoting -- in other general terms they are "small DSLs")

* More vibrant community

* Faster (Warp is screaming fast)

* More like Rails (yups this is an advantage to me as I quite liked Rails for some reasons that Yesod seems to copy)

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#85
post #40
post #6

I have one question about yesod: how easy is it to switch templating languages? I had a look at it more than once, but hamlet always turned me off. Is it easy to switch to, say, hastache?

Can anyone please explain me why I got downvoted for asking a question about the linked framework?

I think your question is valid and upvoted you for it.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#86
post #5

Earlier quoted context omitted.

I don't think this comparison is accurate at all. I suspect the author has only used Snap and not Yesod. Actually I don't know if there is a single Haskell programmer that has seriously tried all three web frameworks.

As someone who gave up on yesod because it is so railsish and moved to snap, I'd say it is pretty accurate.

> gave up on yesod because it is so railsish

So what exactly do you feel is bad about "railsishness"?

I think Rails brought a lot of sane defaults and best-practices to a web framework.. I'm not surprised to see nearly all web frameworks that came after it borrow from it. See for instance "Play" on Java/Scala -- very new, very Rails.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#87
post #29
post #5

Earlier quoted context omitted.

I don't think this comparison is accurate at all. I suspect the author has only used Snap and not Yesod. Actually I don't know if there is a single Haskell programmer that has seriously tried all three web frameworks.

As someone who loves yesod, this feels kind of accurate, but I don't see it as a bad thing. Yesod is what a type-safe Rails should look like.

Type-safe, pure-functional Rails; or simply Rails in Haskell.

So not OO, and (opinion warning) a lot less "magic". Template Haskell and QuasiQuoting can be seen as "magic", but I dont think so; they are actually very transparent ways of making small DSLs (a common practice in Ruby-land) w/o the "Ruby magic" needed to create them.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#88
post #60

Earlier quoted context omitted.

Hmm, I'm sorry to have (mis)spoken for you. I assumed you would tell him that since you appear to have been pretty open about it on the mailing list and in IRC. So you think happstack-server is better than snap-server? Or just that I am over-stating the difference? 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 bet…

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…

Great write-up, thanks!

> 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.

https://github.com/aslatter/happstack-wai

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#89

Earlier quoted context omitted.

I am certainly biased, but these are all objective measurements. I am not claiming that the Yesod community is better, just that it is more active. I am sorry you didn't have a good experience. If you can point to specifics of inflexibility that can help us re-think our design.

How did you measure the number of yesod, snap and happstack users? "Objective measurement" means something. Keep in mind, "there's more traffic on mailing list X" doesn't mean there's more users of software X, it means there's more users asking questions about it. Given that yesod is much larger, it doesn't seem terribly unreasonable for there to be more questions about using it. I think you've been displaying the in…

I concur. The comments from Greg on this article are rife with exactly what you're describing. I have avoided Yesod so far because something about the way the Yesod developers conduct themselves rubs me the wrong way. Now I know what it is.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#90
post #84

Earlier quoted context omitted.

http://ycombinator.com/newswelcome.html This isn't reddit, please spare us the memes and +1s. I think the odds of such a contribution being well received are quite low given the hostility to that notion the developers of yesod still display. Given that I can't see any benefit to using yesod, it seems like a waste of time for me to contribute an unwanted template engine to it.

> This isn't reddit, please spare us the memes and +1s. Ok. Yr right, point taken. > I think the odds of such a contribution being well received are quite low given the hostility to that notion the developers of yesod still display. Hostility I've never encountered. I think the Yesod is super welcoming contribs (the recent discussion on pipes/conduits being a great example of that). > Given that I can't see any benef…

The hostility is on display right here, just asking how hard it is to use another template engine gets you a "hamlet is the best" response from one of the devs.

Your list of benefits is a list of things you like. Telling me what you like doesn't make it so that I also like what you like. Yesod offers no advantages to me, as I would be using it without hamlet and without persistent, making it just an uglier happstack or snap. As I said elsewhere, I am one of the significant number of people who feel yesod's over-use of template haskell and qq is unnecessary and detrimental. It seems to appeal primarily to non-haskellers.

Post reply on HN