I gave haskell a shot as some of my earlier github repos indicate:
https://github.com/substack. I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet.
Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use.
I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf.
Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node.
I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense.
The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.
Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use.
I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf.
Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node.
I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense.
The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.