They actually occupy radically different spaces. Arrows are a generalized computational tool, along the lines of applicative functors and monads. Conduits are basically the next step from iteratees. Iteratees are essentially a functional/compositional way of dealing with I/O. Prior to iteratees, you essentially had to choose between using lazy I/O and ignoring the problems or writing C in Haskell if you needed performance and determinism. Conduits take the benefits of iteratees, simplify the coding and give you more concrete guarantees about when resources will be acquired and released.
In fact conduits/pipes/iteratees are all more useful than arrows outside academia. The only library you're likely to encounter arrows in is HXT and there are other XML libraries. You're likely to encounter one of the conduit/pipe/iteratee libraries using any Haskell web framework and probably any other system doing a lot of I/O where guarantees need to be had.
I haven't yet seen evidence that arrows are actually useful at all outside very limited circumstances. The difficulty of learning them and using them is exacerbated by the fact they have something like 11 laws you must obey to create your own arrow versus three for a monad. There's also a lot more going on in the pretty arrow syntax than in do-notation, which desugars pretty easily by comparison. It would all be justified, I suppose, if using arrows enabled crazy functionality that isn't available via simpler abstractions, but that just doesn't seem to be the case.
In fact conduits/pipes/iteratees are all more useful than arrows outside academia. The only library you're likely to encounter arrows in is HXT and there are other XML libraries. You're likely to encounter one of the conduit/pipe/iteratee libraries using any Haskell web framework and probably any other system doing a lot of I/O where guarantees need to be had.
I haven't yet seen evidence that arrows are actually useful at all outside very limited circumstances. The difficulty of learning them and using them is exacerbated by the fact they have something like 11 laws you must obey to create your own arrow versus three for a monad. There's also a lot more going on in the pretty arrow syntax than in do-notation, which desugars pretty easily by comparison. It would all be justified, I suppose, if using arrows enabled crazy functionality that isn't available via simpler abstractions, but that just doesn't seem to be the case.