Question: Arrows seem to be gaining popularity in the Haskell community, but it seems to me like Monads are more powerful. What is gained by using Arrows? Why can't Monads be used instead?

Answer: 
I've always found it difficult to think of the issue in these terms: what is gained by using arrows. As other commenters have mentioned, every monad can trivially be turned into an arrow. So a monad can do all the arrow-y things. However, we can make Arrows that are not monads. That is to say, we can make types that can do these arrow-y things without making them support monadic binding. It might not seem like the case, but the monadic bind function is actually a pretty restrictive (hence powerful) operation that disqualifies many types.

See, to support bind, you have to be able to assert that that regardless of the input type, what's going to come out is going to be wrapped in the monad.

```
(>>=) :: forall a b. m a -> (a -> m b) -> m b

```

But, how would we define bind for a type like `data Foo a = F Bool a` Surely, we could combine one Foo's a with another's but how would we combine the Bools. Imagine that the Bool marked, say, whether or not the value of the other parameter had changed. If I have `a = Foo False whatever` and I bind it into a function, I have no idea whether or not that function is going to change `whatever`. I can't write a bind that correctly sets the Bool. This is often called the problem of static meta-information. I cannot inspect the function being bound into to determine whether or not it will alter `whatever`.

There are several other cases like this: types that represent mutating functions, parsers that can exit early, etc. But the basic idea is this: monads set a high bar that not all types can clear. Arrows allow you to compose types (that may or may not be able to support this high, binding standard) in powerful ways without having to satisfy bind. Of course, you do lose some of the power of monads.

Moral of the story: there's nothing an arrow can do that monad cannot, because a monad can always be made into an arrow. However, sometimes you can't make your types into monads but you still want to allow them to have most of the compositional flexibility and power of monads.

Many of these ideas were inspired by the superb [Understanding Haskell Arrows](http://ertes.de/new/tutorials/arrows.html "Understanding Haskell Arrows") ([backup](http://vrici.digitalkingdom.org/%7Erlpowell/media/public/haskell_arrow.txt "Understanding Haskell Arrows: backup"))
The question isn't quite right. It's like asking why would you eat oranges instead of apples, since apples seem more nutritious all around.

Arrows, like monads, are a way of expressing computations, but they have to obey a different set of [laws](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t%3aArrow). In particular, the laws tend to make arrows nicer to use when you have function-like things.

The Haskell Wiki lists a [few introductions](http://www.haskell.org/haskellwiki/Arrow#External_links) to arrows. In particular, the [Wikibook](https://en.wikibooks.org/wiki/Haskell/Understanding_arrows) is a nice high level introduction, and the [tutorial](http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf) by John Hughes is a good overview of the various kinds of arrows.

For a real world example, compare [this tutorial](http://jaspervdj.be/hakyll/tutorials/03-arrows.html) which uses Hakyll 3's arrow-based interface, with roughly [the same thing](http://jaspervdj.be/hakyll/tutorials/03-rules-routes-compilers.html) in Hakyll 4's monad-based interface.