Live data from Hacker News

High-Performance Web Applications in Haskell

qconlondon.com

21–30 of 31 posts

Re: High-Performance Web Applications in Haskell

#21
post #4
post #3

I 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…

shd point out therre's lots of other resources e.g. Graham book, school of Expression, etc (and for all the folks that have been doing scala, ocaml, erlang, F#, some of te concepts will be familiar

http://stackoverflow.com/questions/16918/beginners-guide-to-...

http://stackoverflow.com/questions/1012573/how-to-learn-hask...

Re: High-Performance Web Applications in Haskell

#22
post #19
post #11

Earlier quoted context omitted.

They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME". Type Systems: Haskell and…

For correctness, both Haskell and Erlang have Quick Check, which is simply fantastic. Quick Check is somewhat easier to use with stateless code, which favours Haskell over Erlang. http://www.cse.chalmers.se/~rjmh/QuickCheck/

For more correctness, scala has had interop hiccups

http://lampsvn.epfl.ch/trac/scala/ticket/2991

http://stackoverflow.com/questions/3313929/how-do-i-disambig...

(and does Orig. Commenter have examples of clojure hiccups? Interop is very important to both (and F#). Maybe a more meaningful compare/contrast is haskell, scala and F# (which I can't do)

http://matt.might.net/articles/best-programming-languages/

---------------

http://james-iry.blogspot.com/2010/05/types-la-chart.html

(his league table of "Most Powerful Type Systems": Agda, epigram, scala, haskell

Re: High-Performance Web Applications in Haskell

#24
post #11
post #6

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

They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME". Type Systems: Haskell and…

Good overview; a couple nitpicks:

Technically Scala's inference is not Hindley-Milner since you still have to declare method argument types for JVM interop.

The speed difference between Scala and Clojure has less to do with the static/dynamic gap than the fact that Clojure relies upon reflection by default. However, once you identify your bottlenecks, adding type hints to remove reflection is pretty easy.

Good stuff.

Re: High-Performance Web Applications in Haskell

#25
post #9
post #5

Earlier 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…

It depends on what you compare to. Bryan aimed for speed got to 56% of the speed of the C parser he used as a benchmark, using 54 lines of code. The C parser is a 1,672 lines hand-rolled parser that's only does HTTP, while attoparsec is a general purpose library. Bryan wrote about it here: http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-...

Re: High-Performance Web Applications in Haskell

#26
post #25
post #9

Earlier quoted context omitted.

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…

It depends on what you compare to. Bryan aimed for speed got to 56% of the speed of the C parser he used as a benchmark, using 54 lines of code. The C parser is a 1,672 lines hand-rolled parser that's only does HTTP, while attoparsec is a general purpose library. Bryan wrote about it here: http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-...

That's definitely an interesting perspective! Thanks for pointing it out.

Re: High-Performance Web Applications in Haskell

#27
post #16
post #14

Earlier quoted context omitted.

Fair enough. I didn't mean to criticize Haskell. In fact, I'm planning to learn it. I was just surprised that this code was presented as a good example of Haskell's fit to the parsers domain. It would be interesting to see if my perception of this code changes once I get more familiar with the language.

I write a lot of ocaml code (for money, even!) and haven't touched haskell for about four years. I still find the haskell version here easier to read. I imagine what's tripping you up is the operator soup. Whilst ugly (one of the things that turned me off haskell) it is a lot easier to read once you are familiar with basic haskell typeclasses (applicative, functor etc). That said, the ocaml version could definitely b…

Hi there! I do quite a bit of both OCaml and Erlang.

In fact, I borrowed Yojson's json parser for my project (piqi.org). Also, I'm familiar with MPL. It looks very nice, but from what I heard it is fairly immature. And you definitely can't parse HTTP this way :)

Re: High-Performance Web Applications in Haskell

#28
post #11
post #6

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

They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME". Type Systems: Haskell and…

Just adding to the list that Erlang has optional type specifications, used only for analysis. http://www.erlang.org/doc/reference_manual/typespec.html

Re: High-Performance Web Applications in Haskell

#29
post #19
post #11

Earlier quoted context omitted.

They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME". Type Systems: Haskell and…

For correctness, both Haskell and Erlang have Quick Check, which is simply fantastic. Quick Check is somewhat easier to use with stateless code, which favours Haskell over Erlang. http://www.cse.chalmers.se/~rjmh/QuickCheck/

On the contrary, QuickCheck is brilliant at testing stateful systems, as long as you can model the actions that occur and how they modify state (statem in eqc helps here).

Re: High-Performance Web Applications in Haskell

#30
post #11

Earlier quoted context omitted.

They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME". Type Systems: Haskell and…

Good overview; a couple nitpicks: Technically Scala's inference is not Hindley-Milner since you still have to declare method argument types for JVM interop. The speed difference between Scala and Clojure has less to do with the static/dynamic gap than the fact that Clojure relies upon reflection by default. However, once you identify your bottlenecks, adding type hints to remove reflection is pretty easy. Good stuff.

A minor nitpick-nitpick: it's not so much that a JVM requirement prevents Scala from using H-M type inference, it's that H-M doesn't work very well with subtyping, which Scala supports for its own O-O reasons. This comment from Martin provides some context: http://www.codecommit.com/blog/scala/is-scala-not-functional...
Post reply on HN