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

¿Cuál es la diferencia entre un futuro y una promesa? (En Akka y Gpars.)

A mí me parecen iguales, ya que ambos bloquean y devuelven el valor del futuro cuando se llama a get y se promete obtener el resultado de un futuro.

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, a Futurees esencialmente una referencia de solo lectura a un valor aún por calcular. A Promisees más o menos lo mismo, excepto que también puedes escribirle . En otras palabras, puede leer tanto de Futures como de Promises, pero solo puede escribir en Promises. Puede obtener el Futureasociado con a Promisellamando al futuremétodo en él, pero la conversión en la otra dirección no es posible (porque sería absurdo).

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 un proxy para un resultado que inicialmente se desconoce, generalmente porque el cálculo de su valor aún está incompleto.

Algunas bibliotecas pueden elegir llamarlos de una manera, algunos pueden elegir llamarlos de otra manera. Y cada vez, se pueden implementar 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 las personas), este enlace sugiere que en Scala esta práctica común.

Como sugirió @ Ptharien's Flame, en Scala a Futurees una operación de solo lectura, mientras que a Promisele brinda la capacidad de producir un resultado (o falla) para la operación que representa.

PromisePor lo tanto, el código responsable utiliza mejor A para llevar a cabo la operación para propagar el resultado, mientras que a Futurese utiliza para exponerlo al código del cliente, que a su vez esperará el resultado. Pero nuevamente, tenga en cuenta que esta distinción es específica de Scala y puede confundir a los extraños.

Agregaré un poco aquí porque últimamente he estado trabajando con una gran cantidad de Futuros en Java, 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 get y el bloqueo; nunca haga esto fuera de las pruebas.

Cuando enseño conceptos de FP y concurrencia en mi rol actual, primero le digo al estudiante que las promesas semánticas y los futuros son sinónimos porque, como consumidor de una promesa o 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 puede completarse y que una promesa sí puede (por ejemplo, según scala / akka / play apis) es demasiado simplista:

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

Algunas promesas no se pueden completar Del mismo modo, en la API de promesa de juego no se puede cumplir una promesa, pero un compromiso canjeable puede, por lo tanto, el juego presenta una semántica diferente, incluso estando bajo el paraguas de Typesafe. Además, Play promise API puede convertir con futuros de scala en ambas direcciones: (F.Promise.wrap (future) o promise.wrapped ()).

Al trabajar con la tecnología Typesafe en Java8, a menudo irá de un lado a otro entre futuros / promesas simplemente porque es preferible una API (Play Promise API parece mejor con lambdas Java8). En Akka + Play + Java8 tomarás futuros de los actores y los envolverás en promesas, componiendo devoluciones de llamadas y devolviéndolos desde el controlador.

Entonces, como le digo a la gente cuando enseño, Promesas y Futuros son más o menos sinónimos.