Why do we need scalaz.stream over iteratee?

Question

Recently, I've been playing with scalaz.iteratee and Play's iteratee. I think that iteratee is a great idea to provide modularity instead of the old imperative while loop -- the aim is to use a function as a handler of each new line instead of getting string[] out of file.

However, when I look at the feature overview of scalaz.stream, it mentions that the design of that is to supersede the old iteratee implementation, but it doesn't mention why they want to replace it.

Can someone explain to me if we can Stream, what feature and benefits we can obtain and also what is drawback of using iteratee?

Penmanship

Answer 1

Iteratee is much harder to work with compare to scalaz-stream. Scalaz-stream as well are superior to iteratees in terms of code-reuse and composition.

In fact the whole "servers" can be now implemented in scalaz-stream instead just small programs or pieces of code like with Iteratee pattern.

Scalaz-stream gives you superior resource safety, termination reason propagation, fine-tuned concurrency control, tons of combinators and is easy to extend.

We have now project that is 200K + scalaz stream code, and is complex multi-user multi-homed clustered server(s), all implemented in scalaz stream.

If you would share on what really you want to achieve I can be more "exact" in benefits and give you some quick code samples, that hopefully will prove claims above :-)

Trujillo

Thanks for your answer, but I think I need more details or code sample to demonstrate stream over iteratee. For example, as far I am concerned right now, The "easy to extend" is fine for iteratee pattern. If I want to define head, drop or even map, I can define a method which return a iteratee to do that. Also, if I want to include the record lineNumber of the file, I can change Element case class to Element(x: E, lineNumebr: Int). For other things like "termination reason propagation, fine-tuned concurrency ", I am not sure. – Penmanship