I'm currently exploring Haskell and how suitable it would be for web development. I've been toying around with Haskell a little previously, but I have absolutely no idea of what to expect when it comes to web frameworks in Haskell. I'm currently looking at two alternatives: Snap and Yesod. I thought it might be useful to record my first impressions and observations as I experience them. Perhaps material for a future blog post…
I'm installing Snap version 0.4.1 and Yesod version 0.8 on two machines running Mac OS X 10.6.7, Xcode 4.0.2, GHC 7.0.3 (trying both 32 and 64-bit versions) and Haskell Platform 2011.2.0.1.
I was happy to note that both of the frameworks are available from cabal. That means installation should be easy, right? Well…
At this point in time 32-bit GHC, Xcode 4 and some packages don't play well together: both of the installs failed with the following error message from cabal while installing some dependency.
`sorry, unimplemented: LLVM cannot handle register variable ‘R1’, report a bug`.
After some Googling I found a way to force GHC use native code generation (-fasm) and GCC 4.2 instead of LLVM-GCC when a package uses -fvia-C compiler flag (-pgmc=/usr/bin/gcc-4.2). See this gist for details.
(On a 64-bit GHC I curiously didn't encounter any problems.)
Here are my first three thoughts based on the installation experience.
I was rather surprised to face the problems I did with the recommended 32-bit GHC version and an up-to-date Mac OS X. Installation is the one thing that needs to go smoothly—at this point it's still so easy to give up, and it's also the time when first impressions are formed. Luckily on this occasion the problems were easily solved.
I realize that Xcode 4's shift from GCC to LLVM-GCC by default is a major change, and some problems are to be expected. Still, I get the impression that GHC devs aren't following Mac OS X very closely—GHC 7.0.2 didn't work with Xcode 4 at all. It was known well in advance that LLVM-GCC would be the new default, and it has been available since Xcode 3.
I'm not sure how to best make sure installation always works—perhaps some sort of CI task that builds the framework running on all supported platforms?
Both of these frameworks seem to be built from a lot of small pieces. Python famously comes with “batteries included” and one of the goals of Haskell Platform is to collect a similar set of stable and widely used libraries. I was a little surprised to see just how many dependencies both of these frameworks have already collected besides the packages in Haskell Platform. Perhaps Haskell Platform isn't big enough yet?
On the other hand, clear separation of concerns gives hope that it might be easier to mix and match packages than in Django for example.
GHC warning output seems to be quite verbose by default. There are a lot of warnings for redundancy, deprecation, shadowing, overlapping pattern matches, etc—see the above gist for yourself. This should be a good thing: if the warnings are meaningful, developers should be able to discover and fix the problems pretty quickly.
However, there are some warnings like this which go way too far in the details for a casual Haskell / GHC user:
SpecConstr
Function `$wa{v shhm} [lid]'
has one call pattern, but the limit is 0
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
Should I know what SpecConstr is? I guess this is some sort of debug output for some optimization GHC tried to apply. I have no idea why an end user needs to see this information, and if they really do, it should be worded in a more meaningful way. There are bugs filed regarding this issue here and here.
Another frequently encountered warning when using the 64-bit version of GHC comes from the linker:
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame
This again seems to be some sort of incompatibility with Mac OS X 10.6, LLVM-GCC and GHC. A relevant bug has been filed here.
Both of the frameworks create scaffolding to bootstrap a new project. Both also integrate tightly with cabal, creating a .cabal configuration file in the process. Both also need to compile and install additional dependencies at this point. Why not simply mark them as dependencies for the framework, if you can't build a simple “hello world” app without them?
Whereas snap init simply fills the current directory with scaffolding, Yesod launches a somewhat chatty prompt asking for your name and a few other things. One of these things was the name for my project’s “foundation datatype”. I still have absolutely no idea what that is supposed to mean.
Launching the skeleton app is easy in both cases. Snap creates a new cabal package based on the project's name and you simply run the generated binary. With Yesod you run yesod devel.
Overall, following both five minute tutorials was a straightforward and easy process.