What is the difference between a Future and a Promise?

Question

What is the difference between a Future and a promise? (In Akka and Gpars.)

They look the same to me as both block and return the value of the future when get is called and a promise is to get the result of a future.

Answer 1

I'll talk about Akka/Scala, because I'm not familiar with Gpars nor with Akka/Java.

In Scala 2.10, which includes the relevant part of Akka in the standard distribution, a Future is essentially a read-only reference to a yet-to-be-computed value. A Promise is a pretty much the same except that you can write to it as well. In other words, you can read from both Futures and Promises, but you can only write to Promises. You can get the Future associated with a Promise by calling the future method on it, but conversion in the other direction is not possible (because it would be nonsensical).

Answer 2

According to wikipedia, they are the same concept:

In computer science, future, promise, and delay refer to constructs used for synchronizing in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete.

Some libraries may choose to call them one way, some may choose to call them another. And each time, they may be implemented in different flavors. Some libraries may choose to use these synonyms to distinguish different flavors. While I would argue that this is a bad choice (because evidently it confuses people), this link suggests that in Scala this common practice.

As @Ptharien's Flame suggested, in Scala a Future is a read-only operation, while a Promise gives you the ability to yield a result (or failure) for the operation it represents.

A Promise is thus best used by the code responsible to carry out the operation to propagate the result, while a Future is used to expose it to client code, that will in turn await the result. But again, please note that this distinction is Scala specific and may confuse outsiders.

Answer 3

I'll add a bit here because I have been working with a plethora of Futures in Java as of late but have a background in Scala/Akka development as well. This answer will mostly duplicate what has been said but will point out the plethora of implementations in popular use today on the JVM.

First, original poster mentions using get and blocking - please never ever do this outside of tests.

When I teach FP and Concurrency concepts in my current role, I first tell the student that semantically promises and futures are synonyms because as a consumer of a promise or a future api, the developer does not need to understand that there are or IF there are semantic differences - only the mechanics for handling them without blocking IO.

To say that a future can't be completed and that a promise can (eg as per scala/akka/play apis for example) is too simplistic:

Some Futures can be completed Java8 now introduces a CompletableFuture into the standard library.

Some Promises can't be completed Similarly, in the Play promise API a Promise can't be fulfilled but a RedeemablePromise can so play introduces a different semantic - even while being under the Typesafe umbrella. Further, Play promise API can convert with scala futures in both directions - (F.Promise.wrap(future) or promise.wrapped()).

Working with Typesafe technology on Java8 you will often go back and forth between futures/promises simply because one API is preferable (Play Promise API seems better with Java8 lambdas). On Akka+Play+Java8 you will be taking futures from Actors and wrapping them into promises, composing callbacks, and returning that from the controller.

So, as I tell people when I teach, Promises and Futures are more or less synonyms.