Scala streaming library differences (Reactive Streams/Iteratee/RxScala/Scalaz...)

Question

I'm following the Functional Reactive Programming in Scala course on Coursera and we deal with RxScala Observables (based on RxJava).

As far as I know, the Play Iteratee's library looks a bit like RxScala Observables, where Observables a bit like Enumerators and Observers are bit like Iteratees.

There's also the Scalaz Stream library, and maybe some others?

---

So I'd like to know the main differences between all these libraries. In which case one could be better than another?

---

PS: I wonder why Play Iteratees library has not been choosed by Martin Odersky for his course since Play is in the Typesafe stack. Does it mean Martin prefers RxScala over Play Iteratees?

---

Edit: the Reactive Streams initiative has just been announced, as an attempt to standardize a common ground for achieving statically typed, high-performance, low latency, asynchronous streams of data with built-in non-blocking back pressure

Scuba

Not an answer, but see my question here and Rúnar's response for some comparison of streams and iteratees (although to be honest, as compelling as that stream implementation is, I'm still mostly using iteratees). – Ladylike

@TravisBrown thanks, I saw that post but it's kind of heavy stuff for a reactive programming beginner. Will look at it more attentively later. Is Scalaz Iteratee a bit like Play Iteratee? Because I don't remember having seen any monad transformers in Play library – Scuba

Yes, Play and Scalaz have different iteratee APIs but the idea is essentially the same. One big difference is that Play's is less generic—where Scalaz's is parameterized on an arbitrary monad, Play has Future baked in. – Ladylike

Answer 1

PS: I wonder why Play Iteratees library has not been choosed by Martin Odersky for his course since Play is in the Typesafe stack. Does it mean Martin prefers RxScala over Play Iteratees?

I'll answer this. The decision of which streaming API's to push/teach is not one that has been made just by Martin, but by Typesafe as a whole. I don't know what Martin personally prefers (though I have heard him say iteratees are just too hard for newcomers), but we at Typesafe think that Iteratees require too high a learning curve to teach them to newcomers in asynchronous IO.

At the end of the day, the choice of streaming library really comes down to your use case. Play's iteratees library handles practically every streaming use case in existence, but at a cost of a very difficult to learn API (even seasoned Haskell developers often struggle with iteratees), and also some loss in performance. Other APIs handle less use cases, RX for example doesn't (currently) handle back pressure, and very few of the other APIs are suitable for simple streamed parsing. But streamed parsing is actually a pretty rare use case for end users, in most cases it suffices to simply buffer then parse. So Typesafe has chosen APIs that are easy to learn and meet the majority of the most common use cases.

Collateral

That's right. When you have a programming abstraction like Iteratees that is more complicated to reason about than vast majority of the applications that abstraction is going to be used to build, then its a problem. And I don't believe that it is not possible to have a simpler abstraction to solve the same set of problems. @james-roper , are there use cases where reactive-streams is inferior to Iteratees ? – Gallipot

Reactive streams is not an alternative to Iteratees, it is an API for streaming library interoperability. We have an iteratees based implementation of reactive streams in Play so they can be used with Akka streams, RX, whatever. The question you should be asking is whether another reactive streams implementation, eg Akka streams, is better or inferior to iteratees, and the answer to that is, it depends on your use case. But in Play we are moving to Akka streams right now. – Collateral

Answer 2

Iteratees and Stream aren't really that similar to RxJava. The crucial difference is that they are concerned with resource safety (that is, closing files, sockets, etc. once they aren't needed anymore), which requires feedback (Iteratees can tell Enumerators they are done, but Observers don't tell anything to Observables) and makes them significantly more complex.

Krakau

Hi @AlexeyRomanov , isn't the Observable's subscription mechanist, and the unsubscribe method, the point of giving a feedback to the Observable so that it could eventually close the resource? Not sure but it seems strange Netflix uses RxJava if it doesn't manage resource closing because I guess Netflix resources are kind of heavy ones... – Scuba

By the way, I find Observers simpler to understand than Iteratees. – Scuba

"isn't the Observable's subscription mechanist, and the unsubscribe method, the point of giving a feedback to the Observable so that it could eventually close the resource?" If you look at the methods for creating Observables (github.com/Netflix/RxJava/wiki/Creating-Observables), you can see they don't do this, and there are no methods for creating Observables from resources you'd care about closing (files, input streams, etc.). "By the way, I find Observers simpler to understand than Iteratees." Yes, that's what I said. – Krakau

Rx.Net, which RxJava is supposed to be based on, definitely does allow external disposal of the Observable. I've yet to look at RxJava/RxScala, and I don't doubt it doesn't, but it seems completely pointless to me to not support this. MSDN Reference - msdn.microsoft.com/en-us/library/hh229114(v=vs.103).aspx – Chaparajos

@Chaparajos It also disposal of the Observer, and if you want to shut down the Observable when no observers remain, you'll have to implement it yourself, both in Rx.Net and RxJava (AFAIK). RxJava does support this, I just meant that it isn't used in the standard observables (much) and it isn't the major concern the way it is for iteratees. – Krakau

Rx.Net also have the Using and Finally methods for handling resources similar to the equivalent keywords of C# (msdn.microsoft.com/en-us/library/hh229585(v=vs.103).aspx and msdn.microsoft.com/en-us/library/hh212133(v=vs.103).aspx) – Electrotherapy

I was watching an [Introduction to Scalaz Stream][1] given by Paul Chiusano and when asked what the difference between Scalaz-stream and RxScala was that Scalaz-steam is more of a pull architecture while RxScala is a push architecture. Without much experience, I'm assuming that he is talking about which end of the pipe is responsible for initiating data though the pipeline. [1]: youtube.com/watch?v=GSZhUZT7Fyc#t=1576 – Addison