snoyberg

Most people don't think about such things when buying (renting) a new phone. If you do consider it, you're an exception to the rule.

This is false, see the `stack solver` and `stack init --solver` commands. Currently it's using cabal's dependency solver under the surface, but there is work in progress (by multiple parties) to implement a new SAT-based solver, see: https://github.com/commercialhaskell/stack/issues/116

Even without --verify, stackage-update is providing a far more secure setup than what you get from cabal update today (since it downloads over SSL). I didn't want to make GPG configuration an impediment to people using this tool, thereby pushing them towards something even less secure.

Longer term, we need a better answer, most likely using a config file to state your preference, and eventually switching the default to --verify.

I think this answers your question: this new phase of hiring is based on new customer work we need to fill, plus increased community involvement we're planning to have. This is not based on any new investor funding.

This round of hiring is for engineers with experience. We are likely going to be opening another round of hiring in the near future (reading: next 5-9 months) for less experienced developers, but the details around that are still murky.

Actually, the ideas for LTS Haskell came out of conversations I had with Duncan and Mark at ICFP. The original idea was to create a GPS Haskell that would encompass a "best of both worlds." LTS Haskell is a first step towards that, and I'm hoping that Haskell Platform and Hackage ultimately fold this stuff back in.

I went into more detail on this history in the previous blog post: https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixe...

The clientsession package (which is what we use) both encrypts and applies a hash to the payload. Hashing prevents users from tampering with the data, and encrypting prevents inspection of the data. This means that you can even store sensitive data in a cookie without worrying if it's being compromised. (Not to say I recommend that practice, but it is possible.)

There is of course some performance overhead to encrypting, but Felipe's skein package has been highly optimized, and Yesod is still able to achieve ~50,000 req/sec on modest hardware. (Apologies for not having more accurate numbers, I haven't run our benchmark suite on EC2 in over a year.)

I can't answer with certainty what the author means, but the next set of features planned for Yesod is to have tighter client-side integration. We also agree that's where web app development is headed, but we wanted to start with a solid server-side framework before branching into the client side.

I don't think anyone's actually done it, because most of our users really like Hamlet. That said, switching should be a piece of cake. All you need to do is get the textual result from the templating language you're using and apply preEscapedText to it. Since we use blaze-html under the surface, any templating languages using that library's types will automatically work with Yesod.

Of course, support for type-safe URLs will vary by templating languages, so you may have to manually render URLs yourself, but that's doable via getUrlRender.