Scala's futures are wonderful to use. There are two main benefits:
1. They compose, meaning you can construct a Future out of other Futures
2. They work with Scala's for comprehension syntax making them very concise to use.
We use them everywhere in Myna. The one downside with plain futures is it's very easy to forget to handle errors, so we typically have a Future of a Validation. In Scala 2.10 you'd probably use Try in preference. I talk more about futures and our error handling strategy here: http://noelwelsh.com/blueeyes/concurrency.html
Finally, if you use Node.js and think callbacks are the cat's pyjamas you really should check out a futures implementation (not necessarily in Scala). They are a much better abstraction.
While the Future abstraction in Scala is very nice, it is unfortunately not very good in a multi-threaded context. The implementation of Futures contains a lock that, IIRC, locks the outermost object they are contained in. For us, this led to lots of serialization of code that should and could run in parallel. We've unforunately had to remove all our use of Futures until the implementation matches the expected behaviour.
Let me expand: there is nothing in the type system that will make you handle exceptions in Futures, in the way that Option or Either make you handle the failure case. It is easy for a Future to fail and you to never see a stack trace. E.g. this will silently fail:
Future { 1 / 0 }
An alternative is to encode the possibility of failure in the type system by using Future[Validation[E,A]] (replace Validation with Try or Either as the whim takes you). Then the type system will remind you to handle the failure case. See my link above for more (scroll down a bit to see the section on error handling).
I would like to express my flat unhappiness at being linked to not-the-correct-page. Interstitial ad pages can suck shit through ten bricks.
I guess technically dzone isn't an ad page, but I can't find any content on the page other than ads and a top-10 list, so the difference to me is semantic.
As a side note, if you want to avoid creating an ActorSystem (in case you're not actually using the actors part of Akka), you could just create an execution context manually:
implicit val executionContext = ExecutionContexts.fromExecutorService(Executors.newCachedThreadPool())
Disclaimer: This is not really related to futures and akka. I love them. But I just have some comments on the code and on Scala in general.
While I like the concepts in Scala and Akka very much, I have to say that there are some big disadvantages of Scala.
For example, in this code some magic is happening that is not explicitly coded. For example if I look at this val:
implicit val system = ActorSystem("future")
To me it looks like it is not used within the code block, since it is not referenced. However because its an "implicit" it is applied whereever possible. For me this is very unclear. And in fact a lot of Scala-ers say implicits are dangerous creatures.
I also see the "val future" and a callback "future onSuccess". But i would expect that the "onSuccess" would be bound to the future, however I dont see this coupling. Where is this happening? Magic?
While Scala has some very good things, it also has a lot of complexity. And while it might be the "cool new language" out there. It doesnt mean that it simplifies your program. Less code != Better code.
Note: I love scala, but only a subset of it :-). I hate the stacktraces.... Huge!
You got me there :p. But to be honest I dont have a lot of expiernce with clojure and kotlin. More experience with Scala. However I just found out about Kotlin. Purely functional is cool... But i'm not sure if the next gen language is purely functional.
1. They compose, meaning you can construct a Future out of other Futures
2. They work with Scala's for comprehension syntax making them very concise to use.
We use them everywhere in Myna. The one downside with plain futures is it's very easy to forget to handle errors, so we typically have a Future of a Validation. In Scala 2.10 you'd probably use Try in preference. I talk more about futures and our error handling strategy here: http://noelwelsh.com/blueeyes/concurrency.html
Finally, if you use Node.js and think callbacks are the cat's pyjamas you really should check out a futures implementation (not necessarily in Scala). They are a much better abstraction.