I'm using plain old Java 1.6, and am interested in both these libraries.
Having read the documentation, I'm not sure of the differences, if any. Can anyone explain it, or point me at some relevant info? Thanks in advance!
RxJava does a lot more than the ListenableFutures. I'm not familiar with ListenableFutures, but from the docs it seems that it is simply Futures with callbacks and a few simple methods to compose them. On the other hand, RxJava (or the original Reactive Extensions for .NET, which are a huge inspiration to RxJava) models also sequences of values over time - data in motion, basically anything from a stream of mouse moves to a stream of network packets or database results. It also provides various scheduling strategies and many combinators to compose the streams. A good introduction to RxJava and even comparison to the futures is at the wiki page of the project. You can also have a look at Intro to Rx for an introduction to the general concept.
Related
Since this feature is relatively new (mongo 3.6) I found very few java examples.
My questions:
1. What is the best practices for watching change streams?
2. Does it have to be a blocking call to watch the stream? (This means a thread per collection which is less desired)
This is the example I encountered:
http://mongodb.github.io/mongo-java-driver/3.6/driver/tutorials/change-streams/
The blocking call is:
collection.watch().forEach(printBlock);
Thanks,
Rotem.
Change streams make a lot more sense when you look at them in the context of reactive streams. It took me a while to realize this concept has a much broader existence than just the MongoDB driver.
I recommend reviewing the article above and then looking at the example provided here. The two links helped clear things up, and provided insight on how to write code leveraging the reactive streams Mongo driver, which is non-blocking.
Use mongo reactive driver so that it will be non-blocking. And we used this approach and running in production for last one month, no issue.
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
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.
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.
I'm looking for a socket.io client for Scala. I'm well aware of this, but I cringe at the idea of using it in Scala as it wouldn't feel quite natural nor would it allow for an idiomatic implementation. Does any of you, thus, have a suggestion as to where could I find a Scala client?
If so, just the lines for SBT and a link to the doc will suffice as an answer ;)
I'm afraid I don't know any already implemented libraries or apparent solutions for Scala. But I'll present two very simple approaches that should be very easy to use if you have the time to DIY :-)
But of course it really depends on what you want. As you probably already could imagine a plain WebSocket implementation of Java's standard library can be quite efficient if you need to process simple requests. I found one at scala-lang.org implementing a server calculating random numbers. If it is of interest there's also something brewing at the nightly build which might reveal some handy tricks.
If you want to go for simplicity and for pure Scala in all its might the Actors (in particular a RemoteActor) are immensly powerful. It requires Scala on both ends naturally, but it gives you a messaging-system almost instantly. This is a pretty good start-guide if you aren't already familiar with them.
Anyway. If no good library surfaces I hope this helped. Good luck.
After being exposed to scala's Actors and Clojure's Futures, I feel like both languages have excellent support for multi core data processing.
However, I still have not been able to determine the real engineering differences between the concurrency features and pros/cons of the two models. Are these languages complimentary, or opposed in terms of their treatment of concurrent process abstractions?
Secondarily, regarding big data issues, it's not clear wether the scala community continues to support Hadoop explicitly (whereas the clojure community clearly does ). How do Scala developers interface with the hadoop ecosystem?
Some solutions are well solved by agents/actors and some are not. This distinction is not really about languages more than how specific problems fit within general classes of solutions. This is a (very short) comparason of Actors/agents vs. References to try to clarify the point that the tool must fit the concurrency problem.
Actors excel in distributed situation where no data needs to be concurrently modified. If your problem can be expressed purely by passing messages then actors will do the trick. Actors work poorly where they need to modify several related data structures at the same time. The canonical example of this being moving money between bank accounts.
Clojure's refs are a great solution to the problem of many threads needing to modify the same thing at the same time. They excel at shared memory multi-processor systems like today's PCs and Servers. In addition to the Bank account example, Rich Hickey (the author of clojure) uses the example of a baseball game to explain why this is important. If you wanted to use actors to represent a baseball game then before you moved the ball, all the fans would have to send it a message asking it where it was... and if they wanted to watch a player catching the ball things get even more complex.
Clojure has cascalog which makes writing hadoop jobs look a lot like writing clojure.
Actors provide a way of handling the potential interleaving and synchronization control that inevitably comes when trying to get multiple threads to work together. Each actor has a queue of messages that it processes in order one at a time so as to avoid the need to include explicit locks. In this case a Future provides a way of waiting for a response from an actor.
As far as Hadoop is concerned, Twitter just released a library specifically for Hadoop called Scalding but as long as the library is written for the JVM, it should work with either language.
Is there a source, which I could use to learn some of the most used and popular practices regarding Actor-/Agent-oriented programming? My primary concern is about parallelism and distribution limited to the mentioned scheme - Actors, message passing.
Should I begin with Erlang documentation or maybe there is any kind of book that describes the most important building blocks when programming Actor-oriented?
(Most useful examples would be in Scala or F#)
The Erlang and Scala's Akka are most popular and have large community. In case you want to know ML-based style there is JoCaml. They have simple intro text and collection of more formal papers. I'm using JoCaml about two years in my research work and very happy with it. Also, you can find many examples of the F# mailboxes usage to implement actor-style message passing.
For a colorful and interesting explanation I'd recommend to read some entries on this blog
Other than that, we welcome you to the Akka mailinglist!
With regards to the usage of Actors in Scala, you might want to look into the Akka framework. It has good documentation, and here they have a list of articles and presentations with many examples.
You won't find much in the Erlang documentation that explicitly talks about Actors. The documentation and recent Erlang books explain how to use concurrency/distribution/message passing in the Erlang context. As an aside we hadn't actually heard of Actors when we developed Erlang.