Since I have been experimenting with Arrows quite a bit just recently, I feel compelled to add something to the discussion. I too think that Arrow are a beautifully simple and elegant concept. However, once you write production code, you notice quickly that there is a significant difference between a code snippet that's been chosen specifically to illustrate the beauty of Arrows and something else. In my (albeit limited) experience, Arrows are not the answer "to it all" any more than any other clever software design technique is. The moment you need to do things like "apply" an Arrow, you are squarely in the domain of Monads again. So why not write a Monad to begin with? Plus, powerful abstractions that make the code look simple and elegant _always_ come at a price. An Arrow-based stream processor that performs the same task as my monadic BlockIO library does, for instance, results in a module that has half the size the StateT version does. Which is cool. But it is, as of now, also 10 times slower than the monadic version is. Which is not cool at all. It is quite likely that I don't understand Arrows well enough yet to get certain tasks done efficiently with them. But so far my impression is that they are great for certain tasks and not so great for other tasks. Which doesn't really come as a surprise. "One size fits all" doesn't seem to exist in the real world. Peter