Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
4  
"Future promises producer consumers". (But for programming, swap the last two because Futures (zero or more) is analogous to consumption of a value, and Promise (with only the first one able to succeed) is analogous to producing a value.) –  rwong Aug 4 '13 at 21:28
    
The awesome lecture about future/promises on coursera "Principles of Reactive Programming" by Martin Odersky, Erik Meijer, Roland Kuhn: class.coursera.org/reactive-001/lecture, Week 3 –  GKislin Dec 9 at 7:51

5 Answers 5

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).

share|improve this answer
2  
Related: stackoverflow.com/questions/13381134/… –  rwong Aug 4 '13 at 21:30

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.

share|improve this answer

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.

share|improve this answer

In general these terms are synonyms, but there are many, many libraries in many languages that implement these terms. You will need to read the documentation and/or source for the specific classes in question to understand the difference. But whatever differences you find should not be taken to apply to other Promise or Future libraries - those implementors could flip the design decisions and be just as correct.

share|improve this answer
2  
What does it mean in major usage like Akka, GPars, .Net, Erlang, ML, Haskell, etc. –  Suminda Sirinath Salpitikorala Aug 4 '13 at 18:21
1  
@SumindaSirinathSalpitikorala Have you tried Googling it or reading any documentation? –  AAA Aug 4 '13 at 19:34
4  
this low effort post would have questionable value even if posted as a comment. "In general these terms are synonyms, but... You will need to read the documentation..." meh do you know How to Answer? –  gnat Aug 5 '13 at 1:49

As far as I can tell, both promises and futures are the same in theory. In terms of the mentioned libraries, the above also seems to apply.

share|improve this answer
1  
If I use get in a future it blocks. If I do so on a Promise the same happens. Why do I need a Promise? –  Suminda Sirinath Salpitikorala Aug 4 '13 at 16:09
2  
-1 They are not the same in Akka at all. –  Ptharien's Flame Aug 4 '13 at 18:44

protected by gnat yesterday

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.