High-Performance Web Applications in Haskell
qconlondon.com
High-Performance Web Applications in Haskell
1–10 of 31 posts
Re: High-Performance Web Applications in Haskell
#2Can attest to Haskell and Snap being excellent for small web services where you need a boost - especially when concurrency is involved.
Wrote two small services for http://www.webpop.com in Haskell, both based on Snap. One for dynamically resizing images on the fly and one for handling uploads of large files and streaming them straight to Cloudfiles.
In both cases I started by trying node.js (both cases deals with either fetching or sending files from Cloudfiles so IO operations is what takes time) since the problems seemed very suited for node's eventloop model. In both cases node.js really disappointed.
Ended up giving Snap a try and got really surprised at just how well it worked. Performance is amazing, it's not much more code than the node.js version and theres no endless nesting of callbacks. It handles high levels of concurrency incredibly well and both services ended up using around 8MB of memory each - even under load...
Main problem is the lack of libraries that you tend to take for granted in more webby languages, and obviously the learning curve is pretty steep (but also very rewarding).
Re: High-Performance Web Applications in Haskell
#3I had a good experience writing a little web service in Haskell a couple days ago, an autocomplete server. You give it a prefix, and it returns some number of strings in its database starting with that prefix. I wanted it to be fast, and lighter on memory than the approach some people have been doing with Redis, where they store all prefixes in a sorted set:
http://antirez.com/post/autocomplete-with-redis.html
Sounds like a fun toy project, right? I figured I would store everything in a trie, so I could do really fast prefix searches, and then bolt on a REST interface that would send back JSON or JSONP. So I wrote some C code to handle the prefix searching in a JudySL trie (see http://judy.sf.net/ for details; it's a nice library) and bolted that onto Haskell and wrote some bridge code. What I ended up with was a really nice, easy server that took me only a few hours to write, and was every bit as memory-efficient as I'd hoped. Source code here, if anybody's curious:
https://github.com/PeterScott/acdaemon
The learning curve on Haskell, though, is really something. If you really want to see something ridiculous, try looking at the auto-generated library documentation for anything involving regular expressions. The type declarations in Text.Regex.TDFA are like something H. P. Lovecraft might write about.
Re: High-Performance Web Applications in Haskell
#4I had a good experience writing a little web service in Haskell a couple days ago, an autocomplete server. You give it a prefix, and it returns some number of strings in its database starting with that prefix. I wanted it to be fast, and lighter on memory than the approach some people have been doing with Redis, where they store all prefixes in a sorted set: http://antirez.com/post/autocomplete-with-redis.html Sounds…
It's a fair point about Haskell's learning curve. Haskell is different enough from the languages most people have grown up using that--at least in my experience--there are times that simply understanding a few lines of code can take minutes.
On the other hand, that fact has always seemed to me a mark of why it's worthwhile to persevere: as when you are learning mathematics, things can seem entirely opaque until they 'click', but then you've really made an advance in your understanding.
Probably most people are aware of it, but the O'Reilly book _Real World Haskell_ by Bryan O'Sullivan, Don Stewart, and John Goerzen, is a great way to get started. The book is on-line at
http://book.realworldhaskell.org/
Chapter 8 discusses (one of) the Haskell regexp implementation(s), and in particular addresses one of the puzzling aspects: polymorphism in return type. The whole book is excellent.
(I should also point out that another book _Learn You A Haskell_, has just been published, and is well-regarded. I think it assumes rather less programming experience than RWH, and also covers less of the "real-world" aspects. It also can be read on-line, at
and in fact there is a coupon code on that page now for 40% off.)
Also, the Haskell community is, in my experience, extremely helpful and welcoming. People should come and join!
Re: High-Performance Web Applications in Haskell
#5I had a good experience writing a little web service in Haskell a couple days ago, an autocomplete server. You give it a prefix, and it returns some number of strings in its database starting with that prefix. I wanted it to be fast, and lighter on memory than the approach some people have been doing with Redis, where they store all prefixes in a sorted set: http://antirez.com/post/autocomplete-with-redis.html Sounds…
It's a fair point about Haskell's learning curve. Haskell is different enough from the languages most people have grown up using that--at least in my experience--there are times that simply understanding a few lines of code can take minutes. On the other hand, that fact has always seemed to me a mark of why it's worthwhile to persevere: as when you are learning mathematics, things can seem entirely opaque until they…
The place where I've seen Haskell really shine is parsing. Parsers are remarkably easy to write in Haskell, thanks to Parsec and its various spinoff libraries. For example, here's a minimal HTTP request parser that Bryan O'Sullivan wrote by essentially translating part of the RFC into Haskell:
https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC261...
It's 54 lines long, pretty trivial, and here's a really cool part: it parses incrementally on strict bytestrings, so you can just do raw socket recv calls and pass the chunks of input to the parser. Similarly, I wrote a parser for the subset of YAML that beanstalkd uses (as part of the hbeanstalk client library), and it was just 11 lines of code. It's very impressive.
(The concurrency and parallelism stuff is also notably slick, but I haven't had as much occasion to use it. Haskell's aversion to side-effects really pays off sometimes.)
By the way, you're right about the Haskell community being friendly and welcoming -- as you yourself demonstrate. :-)
Re: High-Performance Web Applications in Haskell
#6Could someone comment on Haskell in comparison to Erlang, Clojure or Scala? I felt like when I started choosing between Ruby on Rails and Python/Django, they were so similar that choosing either one would be a fine choice. Now that I'm interested in functional languages too, it seems that comparing Haskell to Erlang is just not the same as Python to Ruby.
Re: High-Performance Web Applications in Haskell
#7I had a good experience writing a little web service in Haskell a couple days ago, an autocomplete server. You give it a prefix, and it returns some number of strings in its database starting with that prefix. I wanted it to be fast, and lighter on memory than the approach some people have been doing with Redis, where they store all prefixes in a sorted set: http://antirez.com/post/autocomplete-with-redis.html Sounds…
It's a fair point about Haskell's learning curve. Haskell is different enough from the languages most people have grown up using that--at least in my experience--there are times that simply understanding a few lines of code can take minutes. On the other hand, that fact has always seemed to me a mark of why it's worthwhile to persevere: as when you are learning mathematics, things can seem entirely opaque until they…
Haskell takes the complex and tames it with a wonderful type system and sensible abstractions; personally I have never been more productive using any other language.
Re: High-Performance Web Applications in Haskell
#8Could someone comment on Haskell in comparison to Erlang, Clojure or Scala? I felt like when I started choosing between Ruby on Rails and Python/Django, they were so similar that choosing either one would be a fine choice. Now that I'm interested in functional languages too, it seems that comparing Haskell to Erlang is just not the same as Python to Ruby.
The main thing that sets Haskell apart is its type systems, there is none better. In addition to the strong type system Haskell is purely functional which means the compiler can reason pretty strongly about an applications side-effects. I'm not sure Erlang or Scala can really compare on either of these things (though I am not an expert on either of those languages). The last big thing I can think of is that Haskell is "lazy" which means it only evaluates values as they are needed, this aspect has its upsides but also many downsides. Laziness can help one write clear concise code but you must be aware of it or things can get a little sticky.
Re: High-Performance Web Applications in Haskell
#9Earlier quoted context omitted.
It's a fair point about Haskell's learning curve. Haskell is different enough from the languages most people have grown up using that--at least in my experience--there are times that simply understanding a few lines of code can take minutes. On the other hand, that fact has always seemed to me a mark of why it's worthwhile to persevere: as when you are learning mathematics, things can seem entirely opaque until they…
The place where I've seen Haskell really shine is parsing. Parsers are remarkably easy to write in Haskell, thanks to Parsec and its various spinoff libraries. For example, here's a minimal HTTP request parser that Bryan O'Sullivan wrote by essentially translating part of the RFC into Haskell: https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC261... It's 54 lines long, pretty trivial, and here's a really cool…
The HTTP request parser doesn't look readable or trivial to me at all.
I'm not familiar with Haskell, so to me the code looks like a mix of high-level declarative and low-level specialized constructs (e.g. skipWhile, takeWhile) interleaved with syntax noise. And it seems to be using quite a lot of external libraries. Also, correspondence of the code with the HTTP spec is completely non-obvious.
In contrast, here's an HTTP response parser I wrote in OCaml using just one library: https://github.com/alavrik/piqi/blob/master/piqi-tools/piqi_... (see lines 26 - 218).
I've just noticed that the code you are referring to is an example. Well, looking at the example, I can hardly come to a conclusion that Haskell shines for parsing.
Re: High-Performance Web Applications in Haskell
#10Earlier quoted context omitted.
The place where I've seen Haskell really shine is parsing. Parsers are remarkably easy to write in Haskell, thanks to Parsec and its various spinoff libraries. For example, here's a minimal HTTP request parser that Bryan O'Sullivan wrote by essentially translating part of the RFC into Haskell: https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC261... It's 54 lines long, pretty trivial, and here's a really cool…
The HTTP request parser doesn't look readable or trivial to me at all. I'm not familiar with Haskell, so to me the code looks like a mix of high-level declarative and low-level specialized constructs (e.g. skipWhile, takeWhile) interleaved with syntax noise. And it seems to be using quite a lot of external libraries. Also, correspondence of the code with the HTTP spec is completely non-obvious. In contrast, here's an…
If you don't know Haskell, and you've never used attoparsec, then I'm not surprised that you don't find that code to be particularly clear or readable. Haskell has a steep learning curve, as I said earlier. This is not a very damning criticism of Haskell's suitability for writing parsing code.
By the way, that long import list is actually just importing some basic stuff from the standard library, and the attoparsec parsing library. One of the persistent minor annoyances of Haskell is writing long lists of module imports.