Akka Futures In Scala With A Simple Example | Hacker News Reader

Akka Futures In Scala With A Simple Example

blog.knoldus.com

47 pointsmmaltiar16 comments

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.

How about onFailure?

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 focussed on a example with a happy flow. In Akka Futures you can handle only error conditions of the following type.

for example we have future onSuccess future onFailure

or we have onComplete, future onComplete { case Success(result) ⇒ doSomethingOnSuccess(result) case Failure(failure) ⇒ doSomethingOnFailure(failure) }

else you can follow what is mentioned by noelwalsh

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.

TIL. I was under the impression that they all ran (more or less) in parellel.

Depends on where and how they are created, but in our case lots of heavy futures were created in the same object. YMMV.

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.

The actual link: http://blog.knoldus.com/2013/01/12/akka-futures-in-scala-wit...

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!

I bet my money on Kotlin.

I dream of the day when I can read the HN comments on a Scala post without the anti-Scala trolls posting.

   future onSuccess { foo } == future.onSuccess(foo)

This is Scala 101. How can you not know this?

As for implicits -- that's an old argument I'm not interested in revisiting.

Thanks noelwelsh couldn't agree more with you

Sorry was not meant as a troll post. Indeed you are right. I got confused by the syntax. My fault.

However consistency in its syntax is something I value in a language. Scala is too much influenced by Java, imho.

B.t.w apart from these kind of things in the language, the biggest thing I really hate about it, is builtin support for XML.. WTF Really?

I would recommend anyone trying to learn functional style of programming to pick up lisp :-)

> I bet my money on Kotlin.

Two weeks ago you were betting your money on Clojure: http://news.ycombinator.com/item?id=4981587

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.

Reply on news.ycombinator.com