Yesod shows people that Haskell can excel in any paradigm. The limiting issue is simply a lack of quality libraries. Hackage may have thousands of libraries available, but I still see gaping holes preventing Haskell from being a viable option in many settings. Below are 2 GSoC proposals to address that.

Make creating interactive web sites simple

Create the building block for modern interactive ("real-time") websites: a library that can use websockets but automatically fallback to other available communication channels. node.js, Erlang, and Scala seem to be the goto solution for interactive websites. But Haskell is a high performance language with the best asynchrounous IO implementation available. Adding another thread costs almost nothing. And yet, node.js is getting all the spotlight! Node.js has several interfaces that use websockets and fall back to other technologies that are available. The Lift framework for Scala received a lot of attention and helped draw users to Scala. Perhaps Lift's biggest selling point has always been interactivity.

Yesod is a great web framework that uses Haskell's type safety to reduce your bugs to as few as possible. And yet, for all of our advantages we still have trouble maintaining a level of productivity of users of dynamic languages because they have more libraries at their disposal. The compelling use case for Haskell then needs to be not just that it can do things better, but that it can also do things which are impossible in a slow language with weak concurrency (i.e. Ruby and Python).

One solution that Rubyists currently use is to do their messaging/interactivity layer with a different toolset. They might drop in a websockets chat servers that uses node.js. This is a great opportunity for Haskell to sneak in the backdoor on these projects.

A Better Persistence layer

What does modern Haskell development have in common with common development practices 30 years ago? Many users still think the best approach to data storage is to write raw SQL queries that are a typo away from failure and require boilerplate serialization.

We have been trying to solve these issues with the Persistent library, but frankly this is still the weak link in our tool-chain. The latest release of Persistent greatly improved the situation, but we just aren't there yet.

We think we have struck on a good design for serialization that can be re-used in different database adapters. Our high-level query interface makes sure your queries are valid, but it can't express every possible query. We have some nice support for writing raw SQL queries and automatically getting back real Haskell records. However, your raw SQL may have errors, and you can't automatically get back a projection of your data. There is a similar situation for the MongoDB backend.

At the end of the summer, we would have great ways to write raw queries in SQL and MongoDB, but have them compile-time verified. The project would also involve investigating ways to accomplish projections.

Apply for GSoC

If you are interested in these Google Summer of Code proposals, please contact myself or Michael Snoyman who would mentor on these projects. Jasper Van der Jeugt, an experienced GSoC student that wrote a websockets library, will also mentor on the interactive websites proposal.

Students certainly aren't limited to the proposals outlined here, and they should ask about the GSoC withing the Haskell community. Alternatively, if you know students that would make a good fit (have existing Haskell experience), please pass the word along.