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.

  • 5
    "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
    Commented Aug 4, 2013 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 Commented Dec 9, 2014 at 7:51
  • 3
    @rwong: "Future promises producer consumers" - huh? Is this meant to be a meaningful sentence that acts as a mnemonic to remind us of the difference between futures and promises? My brain has totally failed to parse it. And also you're saying that it's wrong and needs words swapping, but for some reason you haven't just done this before typing it. And finally it's in quotes, but googling it brings up no hits other than your comment. Mega-baffled.
    – bacar
    Commented Jun 8, 2018 at 10:56
  • I don't have enough reputation to answer this outside of a comment, so I'll answer here. The difference between futures and promises is that futures are typically used by a single thread to call a bunch of functions which execute on other threads, and block until one or more are complete. Promises are special and languages build in async and await to push promises onto an (implicit) job queue and allow resumption of execution after their completion. Promises are usually chained together. Futures typically launch N jobs and waiti for their completion by the calling thread. Commented Sep 6, 2022 at 3:55

3 Answers 3


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


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.

  • This is the case for JS Promises and Python Futures as well. Commented Oct 18, 2017 at 7:01

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.

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