¿Cuál es la diferencia entre un futuro y una promesa?

Hablaré sobre Akka / Scala, porque no estoy familiarizado con Gpars ni con Akka / Java.

En Scala 2.10, que incluye la parte relevante de Akka en la distribución estándar, un Future es esencialmente una referencia de solo lectura a un valor por calcular. Un Promise es más o menos el mismo , excepto que también puede escribir en él . En otras palabras, puede leer tanto de Future s como de Promise s, pero solo puede escribir en Promise s. Puede obtener el Future asociado con un Promise llamando al método future , pero la conversión en la otra dirección no es posible (porque no tendría sentido).

Según wikipedia , son el mismo concepto:

  

En informática, futuro, promesa y retraso se refieren a construcciones utilizadas para la sincronización en algunos lenguajes de programación concurrentes. Describen un objeto que actúa como proxy para un resultado inicialmente desconocido, generalmente porque el cálculo de su valor aún está incompleto.

Algunas bibliotecas pueden elegir llamarlas de una manera, otras pueden elegir llamarlas de otra manera. Y cada vez, pueden ser implementados en diferentes sabores. Algunas bibliotecas pueden optar por utilizar estos sinónimos para distinguir diferentes sabores. Si bien diría que esta es una mala elección (porque evidentemente confunde a la gente), este enlace sugiere que en Scala esta práctica común.

Como sugirió @ Ptharien's Flame, en Scala, Future es una operación de solo lectura, mientras que Promise le da la capacidad de producir un resultado (o falla) para la operación que representa.

Por lo tanto, el código responsable es el que utiliza mejor Promise para llevar a cabo la operación para propagar el resultado, mientras que un Future se usa para exponerlo al código del cliente, que a su vez esperará el resultado. Pero una vez más, tenga en cuenta que esta distinción es específica de Scala y puede confundir a los forasteros.

Agregaré un poco aquí porque he estado trabajando con una gran cantidad de Futuros en Java últimamente pero también tengo experiencia en el desarrollo de Scala / Akka. Esta respuesta duplicará principalmente lo que se ha dicho, pero señalará la gran cantidad de implementaciones de uso popular hoy en día en la JVM.

Primero, el póster original menciona el uso de obtener y bloquear; nunca hagas esto fuera de las pruebas.

Cuando enseño conceptos de PF y Concurrencia en mi función actual, primero le digo al estudiante que las promesas y futuros semánticos son sinónimos porque, como consumidor de una promesa o de una api futura, el desarrollador no necesita entender que hay o SI hay diferencias semánticas, solo la mecánica para manejarlas sin bloquear IO.

Decir que un futuro no se puede completar y que una promesa (por ejemplo, según scala / akka / play apis, por ejemplo) es demasiado simplista:

Algunos futuros pueden completarse Java8 ahora introduce un CompletableFuture en la biblioteca estándar.

Algunas promesas no se pueden completar De manera similar, en la API de promesa de juego una promesa no se puede cumplir, pero un compromiso de canjear puede así presentar una semántica diferente, incluso estando bajo el paraguas de Typesafe. Además, la API Play promise se puede convertir con futuros de escala en ambas direcciones - (F.Promise.wrap (future) o promise.wrapped ()).

Al trabajar con la tecnología Typesafe en Java8, a menudo se alternará entre futuros y promesas simplemente porque es preferible una API (la API de Play Promise parece mejor con las lambdas de Java8). En Akka + Play + Java8, tomará futuros de Actores y los envolverá en promesas, redactará devoluciones de llamada y las devolverá desde el controlador.

Entonces, como les digo a las personas cuando enseño, Promesas y futuros son más o menos sinónimos.