Futures

Agenda

Intro
API imperativo
API de combinadores funcionales
Cómo funcionan
Algunas cosas de cuidado
~~Combinando futuros y actores~~
Futuros en Java
Futuros (promesas) en JavaScript
¿Qué sigue?

Intro

A Future[T] represents a T-typed result, which may or may not be delivered at some time in the future, or which may fail altogether. Like real-world asynchronous operations, a future is always in one of 3 states: incomplete, completed successfully, or completed with a failure."

- FUTURES AREN’T ERSATZ THREADS

Los futures sirven para componer acciones asíncronas y paralelas de forma fácil y razonable.

A Future[T] represents a T-typed result, which may or may not be delivered at some time in the future, or which may fail altogether. Like real-world asynchronous operations, a future is always in one of 3 states: incomplete, completed successfully, or completed with a failure."

- FUTURES AREN’T ERSATZ THREADS

Los futures sirven para componer acciones asíncronas y paralelas de forma fácil y razonable.

Son ideales para cómputos asíncronos que no requieren estado. Por ejemplo consultas externas. También pueden servir para ejecutar side effects asíncronamente.

Historia

Friedman y Wise introdujeron el término promesa en 1976 (The Impact of Applicative Programming on Multiprocessing)

Baker y Hewit (el mismo del modelo de actores) propusieron los futuros implícitos para hacer evaluación paralela en lenguajes funcionales. [The incremental garbage collection of processes (1977)]

Historia

Friedman y Wise introdujeron el término promesa en 1976 (The Impact of Applicative Programming on Multiprocessing)

Baker y Hewit (el mismo del modelo de actores) propusieron los futuros implícitos para hacer evaluación paralela en lenguajes funcionales. [The incremental garbage collection of processes (1977)]

Encyclopedia of Parallel Computing, Volume 4

Las primeras nociones de futuros implicaban que para usar el valor dentro del futuro este debía forzarse (bloquearse)

Historia

Friedman y Wise introdujeron el término promesa en 1976 (The Impact of Applicative Programming on Multiprocessing)

Baker y Hewit (el mismo del modelo de actores) propusieron los futuros implícitos para hacer evaluación paralela en lenguajes funcionales. [The incremental garbage collection of processes (1977)]

Las primeras versiones no hablaban de cómo crear nuevos futuros a partir de otros

Encyclopedia of Parallel Computing, Volume 4

Las primeras nociones de futuros implicaban que para usar el valor dentro del futuro este debía forzarse (bloquearse)

Historia

Aplicaciones en sistemas distribuidos para hacer RPC

Encyclopedia of Parallel Computing, Volume 4

Historia

Aplicaciones en sistemas distribuidos para hacer RPC

Encyclopedia of Parallel Computing, Volume 4

Your Server as a Function

Finagle, la librería de Twitter para hacer RPC, esta cimentada en la composición de Futuros

Los Futuros no son una característica del lenguaje. Existen varias librerías que los implementan, de forma distinta:
- scala.concurrent.Future
- com.twitter.util.Future
- scalaz.Future / scalaz.Task

Los Futuros no son una característica del lenguaje. Existen varias librerías que los implementan, de forma distinta:
- scala.concurrent.Future <- El foco de esta charla
- com.twitter.util.Future
- scalaz.Future / scalaz.Task

Para ejecutar futuros de la librería estándar se requiere tener un ExecutionContext, que es algo que ejecuta código típicamente en un pool de threads.

Los Futuros no son una característica del lenguaje. Existen varias librerías que los implementan, de forma distinta:
- scala.concurrent.Future <- El foco de esta charla
- com.twitter.util.Future
- scalaz.Future / scalaz.Task

Para ejecutar futuros de la librería estándar se requiere tener un ExecutionContext, que es algo que ejecuta código típicamente en un pool de threads.

Scala provee un contexto de ejecución global (que se utiliza haciendo import scala.concurrent.ExecutionContext.Implicits.global), pero para aplicaciones de verdad se sugiere tener varios aislados.

Los Futuros no son una característica del lenguaje. Existen varias librerías que los implementan, de forma distinta:
- scala.concurrent.Future <- El foco de esta charla
- com.twitter.util.Future
- scalaz.Future / scalaz.Task

Future { miCodigo() }

Para ejecutar un bloque de código dentro de un Future basta con hacer:

Future { miCodigo() }

Para ejecutar un bloque de código dentro de un Future basta con hacer:

Intuición

implicit val ec: ExecutionContext = ...
def ejecutarFuturo(): Future[Int] = Future {
    Thread.sleep(2000)
    println("Future completed!")
    4+5
}
ejecutarFuturo()
println("Completed!")

¿Qué se imprime primero?:

Intuición

implicit val ec: ExecutionContext = ...
def ejecutarFuturo(): Future[Int] = Future {
    Thread.sleep(2000)
    println("Future completed!")
    4+5
}
ejecutarFuturo()
println("Completed!")

¿Qué se imprime primero?:

> Completed!
> // suceden cerca de 2 segs
> Future completed!

Algunas ventajas

Tienen una API muy rica que permite:

Algunas ventajas

Tienen una API muy rica que permite:

Despachar trabajo a otros threads

Algunas ventajas

Tienen una API muy rica que permite:

Despachar trabajo a otros threads

Paralelizar y unir resultados fácilmente

Algunas ventajas

Tienen una API muy rica que permite:

Despachar trabajo a otros threads

Paralelizar y unir resultados fácilmente

Fácil de componer

Algunas ventajas

Tienen una API muy rica que permite:

Despachar trabajo a otros threads

Paralelizar y unir resultados fácilmente

Fácil de componer

Pueden documentar explícitamente (a través del tipo de retorno) que una función es asíncrona

Algunas desventajas

No son adecuados para hacer modificaciones concurrentes sobre estado compartido

Algunas desventajas

No son adecuados para hacer modificaciones concurrentes sobre estado compartido

A diferencia de los actores no tiene sentido modelar aspectos del dominio con Futuros. Son mas "operacionales"

Algunas desventajas

A diferencia de los actores no tiene sentido modelar aspectos del dominio con Futuros. Son mas "operacionales"

Es fácil usarlos ignorando los recursos que consumen

No son adecuados para hacer modificaciones concurrentes sobre estado compartido

API imperativo

class Future[T] {

    def isCompleted: Boolean

    def value: Option[Try[T]]

}

El resultado de estas funciones depende de cuando se llamen:

API imperativo

class Future[T] {

    def isCompleted: Boolean

    def value: Option[Try[T]]

}

El resultado de estas funciones depende de cuando se llamen:

None                        // <- No ha terminado
Some(Success(t))            // <- Terminó exitosamente con valor t
Some(Failure(throwable))    // <- Terminó fallidamente con un throwable

value puede retornar uno de tres posibles resultados (dependiendo del momento en el que se llamen):

API imperativo

class Future[T] {

    def isCompleted: Boolean

    def value: Option[Try[T]]

}

None                        // <- No ha terminado
Some(Success(t))            // <- Terminó exitosamente con valor t
Some(Failure(throwable))    // <- Terminó fallidamente con un throwable

El resultado de estas funciones depende de cuando se llamen:

value puede retornar uno de tres posibles resultados (dependiendo del momento en el que se llamen):

Estas funciones NO deberían usarse.

Para "manipular" el valor del futuro hay otras

API imperativo

class Future[T] {

    def onComplete[U](f: (Try[T]) => U)(implicit e: ExecutionContext): Unit

    def onSuccess[U](pf: PartialFunction[T, U])(implicit e: ExecutionContext): Unit

    def onFailure[U](pf: PartialFunction[Throwable, U])(implicit e: ExecutionContext): Unit

}

Funciones de callbacks:

Sirven para mandar a ejecutar cierto pedazo de código una vez se haya resuelto el Futuro con éxito o falla

(onSuccess y onFailure están implementados reusando onComplete)

API imperativo

class Future[T] {

    def onComplete[U](f: (Try[T]) => U)(implicit e: ExecutionContext): Unit

    def onSuccess[U](pf: PartialFunction[T, U])(implicit e: ExecutionContext): Unit

    def onFailure[U](pf: PartialFunction[Throwable, U])(implicit e: ExecutionContext): Unit

}

Funciones de callbacks:

¿Por qué son funciones imperativas?

API imperativo

class Future[T] {

    def onComplete[U](f: (Try[T]) => U)(implicit e: ExecutionContext): Unit

    def onSuccess[U](pf: PartialFunction[T, U])(implicit e: ExecutionContext): Unit

    def onFailure[U](pf: PartialFunction[Throwable, U])(implicit e: ExecutionContext): Unit

}

Funciones de callbacks:

¿Por qué son funciones imperativas?

¿Si transformo el valor del futuro puedo retornar el resultado fácilmente?

¿Si transformo el resultado haciendo otra llamada asíncrona puedo retornar ése resultado?

API imperativo

class Future[T] {

    def onComplete[U](f: (Try[T]) => U)(implicit e: ExecutionContext): Unit

    def onSuccess[U](pf: PartialFunction[T, U])(implicit e: ExecutionContext): Unit

    def onFailure[U](pf: PartialFunction[Throwable, U])(implicit e: ExecutionContext): Unit

}

Funciones de callbacks:

¿Por qué son funciones imperativas?

¿Si transformo el valor del futuro puedo retornar el resultado fácilmente?

¿Si transformo el resultado haciendo otra llamada asíncrona puedo retornar ése resultado?

Funciones que no retornan nada (Unit) no son una buena base para la composición

API de combinadores funcionales

map, flatMap, recover, recoverWith, sequence/traverse

map

map transforma el resultado del Future. Cuando el Future sobre el que se llama map termine se ejecuta la función.
Es una mejor forma de mandar a ejecutar una función después de una acción asíncrona que usando callbacks.
La firma de map es algo como:

class Future[A] {
    def map[B](f: A => B)(implicit ec: ExecutionContext): Future[B] = {
        ...
    }
}

map

Componiendo acciones asíncronas

¿Qué pasa si uno quiere empezar con algo asíncrono y necesita continuar con el resultado de otra acción que también es asíncrona?

Componiendo acciones asíncronas

¿Qué pasa si uno quiere empezar con algo asíncrono y necesita continuar con el resultado de otra acción que también es asíncrona?

def userTrackIds(userId: UserId): Future[List[TrackId]] = { ... }
def tracks(trackIds: List[TrackId]): Future[List[Track]] = { ... }

def userTracks(userId: UserId): Future[List[Track]] = ???

Por ejemplo, ¿cómo obtener los tracks de un usuario dadas las siguientes funciones?:

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    }
}

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    } // <- NO COMPILA!!!!!!!!!!
}

error: type mismatch: 
found: Future[Future[List[Track]]] 
required: Future[List[Track]]

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    } // <- NO COMPILA!!!!!!!!!!
}

error: type mismatch: 
found: Future[Future[List[Track]]] 
required: Future[List[Track]]

hmmm ¿Future[Future[List[Track]]]?

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    } // <- NO COMPILA!!!!!!!!!!
}

error: type mismatch: 
found: Future[Future[List[Track]]] 
required: Future[List[Track]]

hmmm ¿Future[Future[List[Track]]]?

¿Una acción asíncrona que devuelve otra acción asíncrona?

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    } // <- NO COMPILA!!!!!!!!!!
}

error: type mismatch: 
found: Future[Future[List[Track]]] 
required: Future[List[Track]]

hmmm ¿Future[Future[List[Track]]]?

¿Una acción asíncrona que devuelve otra acción asíncrona?

No tiene mucho sentido

Componiendo acciones asíncronas

¿Con map?

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).map { trackIds =>
        tracks(trackIds)
    } // <- NO COMPILA!!!!!!!!!!
}

error: type mismatch: 
found: Future[Future[List[Track]]] 
required: Future[List[Track]]

hmmm ¿Future[Future[List[Track]]]?

¿Una acción asíncrona que devuelve otra acción asíncrona?

No tiene mucho sentido

¿Entonces?

flatMap

La firma de flatMap es es algo como:

class Future[A] {
    def flatMap[B](f: A => Future[B])(implicit ec: ExecutionContext): Future[B] = {
        ...
    }
}

Es decir, a flatMap se le debe pasar una función que devuelva un resultado asíncrono: otro Future

flatMap

La firma de flatMap es es algo como:

class Future[A] {
    def flatMap[B](f: A => Future[B])(implicit ec: ExecutionContext): Future[B] = {
        ...
    }
}

Es decir, a flatMap se le debe pasar una función que devuelva un resultado asíncrono: otro Future

def userTracks(userId: UserId): Future[List[Track]] = {
    userTrackIds(userId).flatMap { trackIds =>
        tracks(trackIds)
    } // <- AHORA SI COMPILA!!!!!!!!!!
}

flatMap

def userTracks(userId: UserId): Future[List[Track]] = {
    for {
        trackIds <- userTrackIds(userId)
        userTracks <- tracks(trackIds)
    } yield userTracks
}

O usando un for-comprehension:

Pueden imaginar que `<-` es un operador dentro de los for-comprehension que sirve para "extraer" el valor del Futuro

for-comprehensions

Siendo e0 una expresión que es de tipo Future y e una expresión que usa p0:

e0.map { p0 => e }

Es lo mismo que:

for {
    p0 <- e0
} yield e

for-comprehensions

e0.flatMap { p0 =>
    e1.flatMap { p1 =>
        e2.flatMap { p2 =>
        ...
        en.map { pn => e }
        }
    }
}

Es lo mismo que:

for {
    p0 <- e0
    p1 <- e1
    ...
    pn <- en
} yield e

La expresión e2 puede utilizar el valor p1, e3 puede utilizar p1 y p2, etc ...
La expresión e puede utilizar todos los valores p0, p1 ... pn

Para paralelismo

val f1: Future[Int] = ejecutarF1() // <- Se empieza a ejecutar
val f2: Future[String] = ejecutarF2() // <- Se empieza a ejecutar
val f3: Future[(Int,String)] = for {
    n <- f1 // <- Se está ejecutando en paralelo a f2
    s <- f2 // <- Se está ejecutando en paralelo a f1
} yield (n+1, "Hola,"+s) // Solo se ejecuta cuando f1 y f2 acaben

flatMap también se puede usar para reunir resultados de varios Futures que se ejecutan en paralelo:

Para paralelismo

val f1: Future[Int] = ejecutarF1() // <- Se empieza a ejecutar
val f2: Future[String] = ejecutarF2() // <- Se empieza a ejecutar
val f3: Future[(Int,String)] = for {
    n <- f1 // <- Se está ejecutando en paralelo a f2
    s <- f2 // <- Se está ejecutando en paralelo a f1
} yield (n+1, "Hola,"+s) // Solo se ejecuta cuando f1 y f2 acaben

flatMap también se puede usar para reunir resultados de varios Futures que se ejecutan en paralelo:

En cambio lo siguiente no se ejecutaría en paralelo:

val f3: Future[(Int,String)] = for {
    n <- ejecutarF1() // <- Se empieza a ejecutar
    s <- ejecutarF2() // <- Solo se empieza a ejecutar cuando se haya resuelto "n"
} yield (n+1, "Hola,"+s) // Solo se ejecuta cuando f1 y f2 acaben