En este tercer artículo sobre programación funcional en JavaScript vamos a hablar de una operación realmente interesante: la transducción. Para ello vamos a tener que valernos de la composición de transformers que vimos anteriormente.

Composición de transformers

Las funciones map y filter que vimos en el artículo anterior tienen una diferencia respecto de las proporcionadas por Array.map y Array.filter: crean funciones que reciben un reducer y devuelven otro reducer.

language-javascript
⁠
⁠⁠⁠// map = (fn) => (reducer) => reducer
⁠
⁠const map = (mapper) => (reducer) => (acc, val) => 
⁠  reducer(acc, mapper(val));
⁠
const filter = (predicate) => (reducer) => (acc, val) =>
⁠  predicate(val) ? reducer(acc, val) : acc;

Lo que significa que nuestros transformers se pueden componer.

language-javascript
⁠
⁠(reducer) => reducer
            ⁠(reducer) => reducer
            ⁠            ⁠(reducer) => reducer ⁠...

Probemos con un ejemplo: podríamos necesitar filtrar primero aquellos elementos de un array que sean menores a 5, y calcular sus cuadrados. Creemos una función filter para la selección, y una función mapper para el cálculo de la potencia, y usémoslos con nuestra función reduce.

language-javascript
⁠⁠
⁠const data = [1, 2, 3, 4, 5];
⁠const lessThanFive = filter((x) => x < 5);
⁠const squares = map((x: number) => power(x, 2));
⁠
⁠const filteredAndSquared = reduce(
⁠  lessThanFive(squares(arrayConcat)),
⁠  data, []
⁠⁠);
⁠console.log(filteredAndSquared); // [1, 4, 9, 16]

Y de nuevo, recordemos que dijimos que la composición es asociativa, pero no conmutativa:

f \circ g \neq g \circ f

De modo que podríamos sacar provecho de ello y, en caso de que fuera necesario, invertir las posiciones de lessThanFive y squares para primero calcular los cuadrados, y después obtener aquellos que son menores a cinco:

language-javascript
⁠
⁠⁠⁠const data = [1, 2, 3, 4, 5];
⁠⁠const squaredAndFiltered = reduce(
  squares(lessThanFive(arrayConcat)),
⁠  data, []
⁠);
⁠console.log(squaredAndFiltered); // [1, 4]

O podríamos necesitar filtrar aquellos elementos cuyos cuadrados son menores que cinco:

language-javascript
⁠
⁠⁠const data = [1, 2, 3, 4, 5];
⁠const isSquareLessThanFive = filter((x) => power(x, 2) < 5);
⁠const filtered = reduce(
⁠  isSquareLessThanFive(arrayConcat), 
⁠  data, ⁠[]
⁠);
⁠console.log(filtered); // [1, 2]

E incluso obtener el cuadrado de cada elemento y reducirlo a un único valor:

language-javascript
⁠
⁠const accumulate = (a: number, b: number): number => a + b;
⁠
⁠⁠⁠const data = [1, 2, 3, 4, 5];
const filteredSquaredAndAccumulated = reduce(
⁠  lessThanFive(squares(accumulate)),
⁠  data,
⁠  0
⁠);
⁠console.log(filteredSquaredAndAccumulated); // 30

Y como nuestros transformers se pueden componer podemos hacer uso de nuestra función compose para todas estas operaciones:

⁠⁠language-javascript
⁠
⁠const compose = (...fns) => (items) =>
  fns.reduceRight((acc, curr) => curr(acc), items);
⁠
⁠⁠⁠const data = [1, 2, 3, 4, 5];
⁠const filterAndSquare = compose(lessThanFive, squares);
⁠
⁠const filteredSquaredAndAccumulated = reduce(
⁠  filterAndSquare(accumulate), data, 0
⁠);
⁠
⁠console.log(filteredSquaredAndAccumulated); // 30

Con esto tenemos ya todas las piezas necesarias para la operación que nos ocupa en este artículo: la transducción.

Transductores

Como decíamos, nuestras funciones filter y map tienen sus análogos en Array.filter y Array.map. Cabría por tanto preguntarse qué sentido tendría implementar nuestras propias funciones cuando el objeto Array ya tiene estos métodos.

Pues bien, planteémonos el siguiente caso: digamos que tenemos un array de gran tamaño, de diez millones de elementos, sobre el que tenemos que realizar diversas operaciones.

language-javascript
⁠
⁠const data = Array.from({ length: 10000000 }, (_, index) => index + 1);

Para procesarlo con Array.map y Array.filter tenemos que guardar primero el array entero en memoria. Y dado que ambos métodos devuelven un nuevo array, cada vez que llamemos a uno de ellos estaremos creando una copia del mismo.

Esto para un array de algunos centenares de elementos no supone un problema. Pero significa que no es un patrón escalable, ya que cuando tengamos una lista de un tamaño relevante podríamos estar consumiendo una cantidad considerable de recursos.

Además podemos tener otro problema: si algo va mal durante el procesamiento de nuestro array, al estar guardando los datos procesados en memoria, si la aplicación sufre algún percance podríamos perder los datos ya procesados.

Todo esto sucede porque los métodos de Array se ejecutan sucesivamente sobre el array completo: esto es, si queremos aplicar Array.map y Array.filter sobre un array, primero map lo recorrerá por completo transformando todos sus elementos y devolviendo un array nuevo, y luego filter hará lo mismo seleccionando aquellos elementos que nos interesen.

language-javascript
⁠
const data = ["1", "2", "3"];
⁠
⁠const result = data
⁠  .map((x) => (console.log("map"), Number(x)))
⁠  .filter((x) => (console.log("filter"), x % 2 !== 0));
⁠console.log(result); // [1, 3]
⁠
⁠// map
⁠⁠// map
⁠⁠⁠// map
⁠⁠⁠// filter
⁠⁠⁠⁠// filter
⁠⁠⁠⁠// filter
// [1, 3]

Sería fantástico si pudiésemos desacoplar el procesamiento de cada elemento individual respecto del procesamiento del array completo.

Para ello podríamos empezar con un cambio: en lugar de hacer pasadas sucesivas sobre el array entero, podríamos intentar realizar primero todas las acciones necesarias sobre el primer elemento, luego sobre el segundo, etc., y así hasta el último elemento.

Pues bien, para lograrlo no nos hace falta hacer nada, porque esto es precisamente lo que ya están haciendo nuestras funciones map y filter con reduce.

language-javascript
⁠
⁠const data = ["1", "2", "3"];
⁠
⁠const toInt = map((x: string) => (console.log("map"), Number(x)));
⁠const isOdd = filter((x: number) => (console.log("filter"), x % 2 !== 0));
⁠const toIntAndFilterOdds = compose(toInt, isOdd);
⁠const result = reduce(toIntAndFilterOdds(concat), data, []);
⁠
⁠console.log(result); 
⁠
⁠⁠⁠// map
⁠⁠⁠// filter
⁠⁠⁠⁠// map
⁠⁠⁠// filter
⁠⁠// map
⁠⁠⁠// filter
⁠// [1, 3]

Si bien parece una diferencia menor, no lo es, ya que nos abre la puerta para transformar reduce en una función que, en lugar de recibir un transformer con un reducer ya aplicado, los reciba por separado y los aplique dentro de sí.

De este modo, en lugar de reducir con la función reduce:

language-javascript
⁠
⁠⁠const reduce = (reducer, iterable, initialValue) => {
⁠  let acc = initialValue;
⁠
⁠  for (const item of iterable) {
⁠    acc = reducer(acc, item);
⁠  }
⁠
⁠  return acc;
⁠};

Usaríamos una nueva función transduce, que tendría el siguiente aspecto:

language-javascript

⁠const transduce = (
⁠  transformer, 
⁠  reducer, 
  ⁠iterable,
⁠  initialValue
⁠) => {
⁠⁠  let acc = initialValue;
⁠  const transformedReducer = transformer(reducer);
⁠
⁠  for (const item of iterable) {
⁠    acc = transformedReducer(acc, item);
⁠  }
⁠
⁠  return acc;
⁠};
⁠
⁠const data = ["1", "2", "3"];
⁠
⁠const toInt = map((x: string) => (console.log("map"), Number(x)));
⁠const isOdd = filter((x: number) => (console.log("filter"), x % 2 !== 0));
⁠const toIntAndFilterOdds = compose(toInt, isOdd);
const result = transduce(toIntAndFilterOdds, concat, data, []);
⁠
⁠console.log(result);
⁠⁠
⁠⁠⁠// map
⁠⁠⁠// filter
⁠⁠⁠⁠// map
⁠⁠⁠// filter
⁠⁠// map
⁠⁠⁠// filter
⁠// [1, 3]

Esto ya es un transductor: una función que toma un transformer —que pueden ser una serie de transformers compuestos— y un reducer —encargado de la operación de reducción—, más un iterable y un dato inicial, y reducirá el iterable sobre el dato inicial usando el transformer y el reducer.

Los transductores tienen una notable ventaja en cuanto a eficiencia frente al encadenamiento de métodos, como sucede con los métodos de Array. Esto se puede ver claro si recuperamos el array de gran tamaño que comentábamos más arriba.

Digamos que tenemos una lista de diez millones de productos con precios diferentes que vendemos a distancia, con un coste de envío de diez dólares. Los usuarios pueden financiar el pago en doce mensualidades, pero sólo si cada cuota mensual resultante es un número entero. Nos han pedido encontrar el mayor gasto que puede hacer un comprador que desee adquirir un producto financiable.

Podemos hacerlo con los métodos de Array:

language-javascript
⁠
⁠// Array with 10.000.000 elements
⁠const data = [
⁠  { name: "Product 1", price: 73 },
⁠  ...
⁠];
⁠
⁠const addShippingCosts = (product: Product) => product.price + 10;
⁠const isEligibleForFinancing = (price: number) => price % 12 === 0;
⁠const getBiggerExpense = (a: number, b: number) => (a > b ? a : b);
⁠
⁠console.time("array_methods");
⁠const result = data
⁠  .map(addShippingCosts)
⁠  .filter(isEligibleForFinancing)
⁠  .reduce(getBiggerExpense);
⁠
console.log(result); // 120
⁠
⁠console.timeEnd("array_methods"); // 141

Bien, obtenemos el resultado correctamente. Tomemos nota del tiempo que lleva ejecutar este código: a la hora de escribir esto el Playground de TypeScript muestra 141 ms., si bien puede cambiar según la máquina donde se ejecute.

Ahora probemos usando un transductor:

language-javascript
⁠
⁠// Array with 10.000.000 elements
⁠const data = [
⁠  { name: "Product 1", price: 73 },
⁠  ...
⁠];
⁠
⁠const eligibleForFinancing = filter(isEligibleForFinancing);
⁠const priceWithShippingCosts = map(addShippingCosts);
⁠const piped = pipe(eligibleForFinancing, priceWithShippingCosts);
⁠
⁠⁠console.time("transduce");
⁠const result = transduce(piped, getBiggerExpense, data, 0);
console.log(result); // 120
⁠console.timeEnd("transduce"); // 62

Como se ve se obtiene el mismo resultado, pero con una ganancia de eficiencia notable. Esto por supuesto dependerá de la complejidad temporal y espacial de los algoritmos que se usen: pero se aprecia que, frente a los mismos algoritmos, los transductores son más eficientes que el encadenamiento de métodos.

Ahora bien, una vez llamamos a transduce, este va a intentar procesar el array entero guardándolo en memoria, con una posible sobrecarga del sistema. En otros términos: el transducer actual es evaluado ansiosamente.

Lo que nosotros buscamos en realidad es una función que nos permita procesar los datos con evaluación perezosa de modo que los datos sean procesados bajo demanda únicamente. Y si recordamos nuestro primer artículo, en él mencionamos que la evaluación perezosa en JavaScript se puede implementar con generadores.

Veamos un ejemplo de un generador:

language-javascript

⁠function* lazySum(a, b) {
⁠  yield a + b;
⁠}
⁠
⁠let result = lazySum(1, 3);
⁠console.log(result); //  {} (not evaluated yet)
⁠console.log(result.next().value); // 4

Por tanto intentemos implementar nuestro transduce para que evalue perezosamente los datos:

language-javascript
⁠
function* lazyTransduce(
⁠  transformer,
⁠  reducer,
⁠  iterable,
⁠  initialValue
⁠) {
⁠  const transformedReducer = transformer(reducer);
⁠  let acc = initialValue;
⁠
⁠  for (const item of iterable) {
⁠    acc = transformedReducer(acc, item);
⁠
⁠    yield acc;
⁠  }
⁠}

En lugar de retornar, lazyTransduce va a devolver un generador que devolverá su estado en acc por cada vez que se ejecute su método next().

language-javascript
⁠
⁠// Array with 10.000.000 elements
⁠const data = [
⁠  { name: "Product 1", price: 73 },
⁠  ...
⁠];
⁠
⁠const eligibleForFinancing = filter(isEligibleForFinancing);
⁠const priceWithShippingCosts = map(addShippingCosts);
⁠const piped = pipe(eligibleForFinancing, priceWithShippingCosts);
⁠
⁠const result = lazyTransduce(piped, getBiggerExpense, data, 0);
⁠
⁠console.log(result.next().value); // 0
⁠console.log(result.next().value); // 0
⁠console.log(result.next().value); // 0
⁠⁠console.log(result.next().value); // 120
⁠⁠⁠console.log(result.next().value); // 120
⁠⁠⁠console.log(result.next().value); // 120
⁠...

Aquí es la evaluación perezosa la que nos va a permitir procesar los datos bajo demanda y realizar acciones sobre los mismos teniendo pleno control sobre el ritmo y periodicidad al que lo hacemos.

Por ejemplo, podríamos querer persistir los datos cada determinado número de elementos, o enviar notificaciones a servicios externos sobre los datos encontrados. Y todo esto podríamos hacerlo además sin causar ninguna sobrecarga del sistema, ya que la complejidad espacial es insignificante y sólo se utilizará la memoria necesaria para cada paso de la iteración.

Y al igual que sucedía cuando usábamos nuestra función reduce, a nuestros transductores podemos pasarles diferentes reducers para acumular los datos de distintas formas. Por ejemplo, concatenando los datos en un nuevo array con concat:

language-javascript
⁠
⁠const data = [
⁠  { name: "Product 1", price: 74 },
⁠  { name: "Product 2", price: 93 },
⁠  { name: "Product 3", price: 110 },
⁠  { name: "Product 5", price: 82 },
⁠];
⁠
⁠const eligibleForFinancing = filter(isEligibleForFinancing);
⁠const priceWithShippingCosts = map(addShippingCosts);
⁠const piped = pipe(eligibleForFinancing, priceWithShippingCosts);
⁠
const result = lazyTransduce(piped, concat, data, []);
⁠
⁠console.log(result.next().value); // [84]
⁠console.log(result.next().value); // [84]
⁠console.log(result.next().value); // [84, 20]
⁠console.log(result.next().value); // [84, 120]
⁠console.log(result.next().done); // true

Hay mucho que decir sobre los transductores, especialmente porque hay numerosas implementaciones: se encuentran detrás de métodos ofrecidos por distintas librerías, como sucede con pipe de RxJS, o son directamente soportados como en el caso de Ramda. Sucede con ellos lo mismo que con otras utilidades: no siempre tiene sentido utilizar las propias por el trabajo y riesgo que conlleva desarrollar la implementación más eficiente posible. Sin embargo es interesante tener presente su existencia y sus fundamentos, ya que nos muestra con claridad su potencial.

Como es habitual, el código se puede ejecutar en el Playground de TypeScript, así como está disponible para descarga en git.antoniodiaz.me.

Si tienes cualquier duda o has encontrado un error no dudes en escribirme a la dirección que figura en el pie.

Voy a iniciar una serie de artículos introductorios a la programación funcional. Abordaré este tema a modo de notas para recién llegados, pero también para mi futuro yo. El objetivo no será cubrir la programación funcional de un modo exhaustivo, sino proporcionar los conceptos y operaciones básicas sobre las que se basa.

La programación funcional se construye sobre operaciones muy comunes, como la composición o la aplicación parcial, desembocando en técnicas y operaciones especializadas, como los transductores. Su objetivo es minimizar los estados compartidos en nuestras aplicaciones, escribir código más declarativo —y por tanto más legible— y, finalmente, módulos más fáciles de testear.

Para esta serie vamos a utilizar un lenguaje común: Javascript. Este es un lenguaje que aunque funciona bien con programación funcional, no es un lenguaje pensado con este paradigma en mente como pueden serlo Erlang o Haskell. Por ello tendremos que implementar numerosas estructuras que en otros lenguajes se encuentran nativamente, lo que nos enseñará bastante sobre este tipo de programación.

Como aquí trataremos la programación funcional de un modo somero, para quien busque una aproximación algo más exhaustiva recomiendo dos recursos:

• Professor Fisby's Mostly Adequate Guide to Functional Programming, Brian Lonsdorf, 2021: https://mostly-adequate.gitbook.io/mostly-adequate-guide.
• Funcional Light Javascript, Kyle Simpson, 2017: https://github.com/getify/Functional-Light-JS/tree/master.

En este primer artículo vamos a desarrollar los conceptos y operaciones más básicas que podemos encontrar en la programación funcional. Hablaremos de:

• Inmutabilidad
• Puridad
• Aridad
• Currying
• Partial application
• Estilo point free
• Compose y pipe
• Evaluación perezosa y ansiosa

Repasaremos cada uno de estos conceptos, presentando ejemplos sencillos en Javascript para mantener todo lo más sencillo posible.

En subsiguientes artículos cubriremos la composición otra vez, pero con la mirada puesta en los tipos y su relación con operaciones de programación funcional más avanzadas.

Inmutabilidad

Uno de los principales problemas que nos podemos encontrar en programación es el estado compartido.

Digamos que estamos trabajando con Javascript, y que tenemos un objeto con una propiedad a, el cual es guardado en memoria en la variable x con cierto valor. Ahora copiamos x en una nueva variable y, lo que significa que hemos copiado la referencia de x en y. A partir de ahora todo lo que hagamos en y lo haremos sobre x también. Como se puede entender esto es problemástico, ya que podríamos cambiar x imperceptiblemente de maneras inesperadas.

language-javascript
⁠
const sherlock = { name: "Sherlock" };
⁠const bilbo = sherlock;
⁠bilbo.name = "Bilbo";
⁠⁠console.log(sherlock); // { name: "Bilbo" }

Para solucionar este problema podemos usar el operador spread ... y extraer las propiedades de john al crear un nuevo objeto bob:

language-javascript

const sherlock = { name: "Sherlock" };
⁠const bilbo = { ...sherlock };
⁠bilbo.name = "Bilbo";
⁠sherlock.name = "Sherlock";
⁠console.log(sherlock); // { name: "Sherlock" }

Hay que tener en cuenta que el operator spread copiará por valor las propiedades en un primer nivel del objeto, pero las anidadas las copiará por referencia con shallow copy. Para evitar este problema podemos usar los métodos que nos provee el objeto JSON.

Otro ejemplo del problema de los estados compartidos podría suceder cuando nos movemos en operaciones concurrentes o que su. En este caso tenemos una operación increment, cuyo resultado es guardado en un objeto sharedState. Pero también tenemos la operación decrement, que computa un nuevo valor, guardándolo también en sharedState. El resultado es un estado compartido: sharedState hace referencia tanto al valor producido por increment como al de decrement. Teniendo en cuenta además que ambas operaciones son impuras, tenemos un código dificil de seguir y de testear.

language-javascript

const sharedState = { type: "shared state", value: 0 };
⁠
⁠const increment = () => {
⁠  sharedState.value += 1;
⁠};
⁠
⁠const decrement = () => {
⁠  sharedState.value -= 1;
⁠};
⁠
⁠increment();
⁠decrement();
⁠decrement();
⁠increment();
⁠decrement();
⁠increment();
⁠
⁠⁠console.log(sharedState); // { type: "shared state", value: 0 }

Este ejemplo no es exactamente concurrente, pero ejemplifica bien la dificultad de seguir el valor del estado compartido a través del flujo de la aplicación. Si además tuviésemos diferentes módulos consumiendo y modificando sharedState podríamos encontrarnos con problemas a la hora de saber cuál es el estado de nuestra aplicación en cada momento de su ejecución.

Este problema se puede solucionar fácilmente eliminando el estado compartido y produciendo uno nuevo con cada operación que se realiza:

language-javascript

const initialState = { type: "non-shared state", value: 0 };
⁠
⁠const increment = (state) => ({
⁠  ...state,
⁠  value: state.value + 1,
⁠});
⁠
⁠const decrement = (state) => ({
⁠  ...state,
⁠  value: state.value - 1,
⁠});
⁠
⁠const stateIncremented = increment(initialState);
⁠const initialState2 = decrement(stateIncremented);
⁠const initialDecremented = decrement(initialState2);
⁠const initialState3 = increment(initialDecremented);
⁠const stateDecremented2 = decrement(initialState3);
⁠const initialState4 = increment(stateDecremented2);
⁠
⁠console.log(initialState4); // { type: "non-shared state", value: 0 }

Los nombres de las variables elegidos no son elegantes ni demasiado expresivos, pero muestran la ventaja de este código frente al anterior: hemos pasado el estado de nuestro programa de una variable mutable cuyo contenido es sólo conocido en tiempo de ejecución, a una variable inmutable cuyo contenido es predecible en tiempo de compilación, motivo por el cual esta nueva versión de nuestro programa será más fácil de comprender, depurar y testear. En este sentido la inmutabilidad facilita la predictibilidad de nuestra aplicación.

Podríamos incluso guardar un histórico de todos los estados de nuestra aplicación, lo que nos facilitaría el proceso de depuración y análisis post-mortem en caso de que surjan problemas.

Puridad

La programación funcional tiene como objetivo la simplicidad y predictabilidad de nuestros programas, de ahí el uso intenso que hace de las funciones. Pero para que las funciones sean predecibles, dado el mismo input deben retornar el mismo output. En este sentido una función reprensenta una relación inmutable entre dos sets: input y output, y esta relación debe mantenerse constante:

language-javascript

⁠const pureFunction = (a, b) => a < b;
⁠console.log(pureFunction(1, 2)); // true
⁠
⁠const impureFunction = (a, b) => (Math.random() > 0.5 ? a < b : a > b);
⁠console.log(impureFunction(1, 2)); // true or false

La puridad facilita la predictabilidad, pero también nos permite memoizar resultados de funciones, evitando computaciones innecesarias.

Aridad

La aridad se refiere al número de parámetros que recibe una función.

• Una función es de aridad 0 cuando no recibe ningún parámetro: es nularia.
• Una función es de aridad 1 cuando recibe sólo un parámetro: es unaria.
• Una función es de aridad 2 cuando recibe sólo un parámetro: es binaria.
• Una función tiene aridad n cuando puede recibir cualquier número de parámetros: es n-aria —también conocida como variádica—.

language-javascript

⁠const nullaryFunction = () => "Hello world";
⁠console.log(nullaryFunction()); // hello world
⁠
⁠const unaryFunction = (greeting) => `${greeting} world`;
⁠console.log(unaryFunction("hello")); // hello world
⁠
⁠const binaryFunction = (greeting, subject) => `${greeting} ${subject}`;
⁠console.log(binaryFunction("hello", "world")); // hello world
⁠
⁠const nAryFunction = (...strings) => 
⁠  strings.reduce((acc, curr) => `${acc}${curr} `, "");
⁠console.log(nAryFunction("hello", "world", "and", "pluton")); 
⁠// hello world and pluton

Nada especial aquí, únicamente algo de terminología. Pero es importante, ya que las funciones unarias están en el centro de algunas operaciones en programación funcional.

Currying

Currying es el proceso de transformar una función que recibe varios parámetros —aridad mayor que 1— en diversas funciones unarias anidadas —funciones que reciben únicamente un parámetro—.

language-javascript

⁠// Non curried function
⁠const sum = (a, b, c) => a + b + c;
⁠const result = sum(1, 2, 3);
⁠console.log(result); // 6
⁠
⁠// Curried function
⁠const sum = (a) => (b) => (c) => a + b + c;
⁠⁠const result = sum(1)(2)(3);
⁠console.log(result); // 6

Como veremos más adelante ésta es una técnica clave en programación funcional: hay muchas operaciones en las que necesitaremos que las funciones tengan una estructura similar —un sólo input para un output—, permitiendo así su combinación en diferentes formas.

Aplicación parcial

La aplicación parcial se refiere al proceso de transformar una función recibiendo diversos parámetros en otra función diferente que recibirá únicamente algunos de esos parámetros, fijándolos en su contexto y devolviendo otra función que recibirá el resto de parámetros, combinándolos con los prefijados.

Esto es realmente útil, puesto que nos permite crear funciones con parámetros preaplicados con anterioridad. Lo que significa que podemos especializar funciones.

Por ejemplo, digamos que tenemos una función createUrl que recibe tres cadenas de texto como parámetros: protocol, domain y path, combinándolos y devolviendo otra cadena:

language-javascript

⁠const createUrl = (scheme, domain, path) => `${scheme}://${domain}/${path}`;
⁠
⁠const httpUrl = createUrl("http", "example.com", "hello");
⁠console.log(httpUrl); // "http://example.com/hello"
⁠
⁠const httpsUrl = createUrl("https", "example.com", "hello");
⁠console.log(httpsUrl); // "https://example.com/hello"

Problablemente usemos esta función en numerosos lugares de nuestro código con "http" o "https". Para escribir código más declarativo y evitar pasar el esquema siempre que necesitemos una urlpodemos crear dos versiones especializadas de createUrl: createHttpUrl y createHttpsUrl , fijando el parámetro scheme en el contexto de dichas funciones:

language-javascript

⁠const createUrl = (scheme, domain, path) => `${scheme}://${domain}/${path}`;
⁠
⁠// Partial application: fixing `scheme` parameter
⁠const createUrlWithProtocol = (scheme) => 
⁠  (domain, path) => createUrl(scheme, domain, path);
⁠⁠
⁠⁠const createHttpUrl = createUrlWithProtocol("http");
⁠const createHttpsUrl = createUrlWithProtocol("https");
⁠
⁠const httpUrl = createHttpUrl("http", "example.com", "hello");
⁠console.log(httpUrl); // "http://example.com/hello"
⁠
⁠⁠const httpsUrl = createHttpsUrl("https", "example.com", "hello");
⁠console.log(httpsUrl); // "https://example.com/hello"

Estas nuevas funciones son más expresivas semánticamente, así como más eficientes, puesto que reducen la aridad de las funciones que utilizamos para crear las urls.

Estilo libre de puntos

El estilo libre de puntos —point-free style en inglés— es una forma de escribir funciones en la que éstas son procesadas sin hacer mención a sus parámetros —puntos—.

Veamos un ejemplo: cuando pasamos una función como parámetro a otra función es práctica común escribirla dentro de ella:

language-javascript

⁠const userName = users.map(
⁠  ({ first, lastName }) => `${first} ${lastName}`
⁠);

En un estilo libre de puntos extraeríamos la declaración de la función para guardarla en una variable, que es lo que pasaremos a la nueva función:

language-javascript

⁠const composeName = ({ first, lastName }) => `${first} ${lastName}`;
⁠const userName = users.map(composeName⁠);

En general el estilo libre de puntos es más declarativo y legible, facilitando la composición de funciones como veremos más adelante.

Compose y pipe

En álgebra la composición de funciones es el proceso de transformar un conjunto secuencial de funciones unarias en otras anidadas, de modo que el resultado de una función se pasará como parámetro a la siguiente envolviéndola.

Digamos que tenemos dos funciones:

f(x) = 2x\\ ⁠⁠g(x) = x^2
⁠
Expresamos que las componemos con la siguiente sintaxis:

f \circ g = f(g(x))

Lo que quieres decir que ejecutamos primero g(x), y después f(x) con el resultado obtenido.

Es importante remarcar que la composición no es conmutativa:

f \circ g \neq g \circ f

aunque sí es asociativa:

f(g(h(x))) = (f \circ g)(h(x)) = f(g(h(x))).

Todo esto se puede traducir a Javascript con facilidad, dado que en este lenguaje las funciones son ciudadanos de primera clase. Esto hace referencia a que podemos tratarlas como variables, de modo que cualquier función pueda aceptar otra como parámetro.

Dadas dos funciones podemos ejecutar una dentro de la otra:

language-javascript

⁠⁠const f = (x) => x * 2;
⁠const g = (x) => x * x;
⁠
⁠const result = f(g(3));
⁠console.log(result); // 18

Y digamos que este tipo de operación es algo que hacemos a menudo: sería interesante si tuviésemos una utilidad que, dadas dos funciones nos las devolviese compuestas:

⁠language-javascript

⁠const f = (x) => x * 2;
⁠const g = (x) => x * x;
⁠
⁠const compose = (f, g) => (x) => f(g(x));
⁠
⁠const composed = compose(f, g);
⁠const resultComposed = composed(3); // 18

En este caso lo que tenemos es una función que recibe dos parámetros —aridad 2—, realiza una aplicación parcial para fijarlos en el contexto de la closura, y devuelve una nueva función que, recibiendo un nuevo parámetro, los usará para ejecutar nuestras funciones anidadas, usando ese nuevo parámetro como argumento inicial.

De esta manera la función devuelta es guardada en la variable composed, que tendrá f y g en su contexto, y hará uso de ellos cuando es llamada con un nuevo argumento —3—.

Ahora digamos que queremos componer tres funciones:

f \circ g \circ h = f(g(x))

Usando la misma lógica podemos traducir esto a Javascript con una función compose de aridad 3:

language-javascript

⁠const f = (x) => x * 2;
⁠⁠const g = (x) => x * x;
⁠const h = (x) => x - 1;
⁠
⁠const compose = (f, g, h) => (x) => f(g(h(x)));
⁠
⁠const composed = compose(f, g, h);
⁠console.log(composed(3)); // 8

Funciona perfectamente; pero no es muy escalable. El siguiente paso sería crear una función variádica que, dado cualquier número de funciones pasadas como parámetros, las devuelve compuestas.

language-javascript

⁠const f = (x) => x * 2;
⁠⁠const g = (x) => x * x;
⁠const h = (x) => x - 1;
⁠
const compose = (...fns) => (x) =>
⁠  fns.reduceRight((acc, curr) => curr(acc), x);
⁠
⁠const composed = compose(f, g, h);
⁠console.log(composed(3)); // 8

Esta función recibe cualquier número de funciones como parámetros individuales, los distribuye en un array con el operador spread ..., y los fija en el contexto de la closura, devolviendo una nueva función. Esta nueva función será unaria, recibiendo a su vez como parámetro el dato inicial para procesar nuestras funciones. Finalmente recorrerá el array de funciones de derecha a izquierda y ejecutándolas, lo que quiere decir que ejecutará primero la última con los datos iniciales proporcionados en el parámetro.

Lo que acabamos de hacer es crear una función compose: una utilidad variádica muy socorrida para componer cualquier número de funciones, siempre y cuando éstas sean unarias.

Ahora digamos que queremos componer nuestras funciones, pero empezando desde la primera hasta la última: en lugar de Array.reduceRight podemos usar Array.reduce:

language-javascript

⁠const f = (x) => x * 2;
⁠⁠const g = (x) => x * x;
⁠const h = (x) => x - 1;
⁠
const pipe = (...fns) => (x) =>
  fns.reduce((acc, curr) => curr(acc), x);
⁠
⁠const piped = pipe(f, g, h);
⁠console.log(piped(3)); // 35

Este tipo de utilidad es conocida como pipe. Como dijimos anteriormente la composición no es conmutativa, por lo que devuelve un resultado distinto a la función compose.

Evaluación perezosa y ansiosa

Por "evaluación ansiosa" nos referimos al modelo de computación en que una variable es evaluada inmediatamente después de que una expresión aparezca en el código.

Por ejemplo, en Javascript:

language-javascript

⁠⁠const sum = (a, b) => a + b;
const result = sum(1, 2); // Computed here
⁠console.log(result); // 3

Como vemos, la expresión es evaluada cuando llamamos a la función, no cuando el resultado de la función es usado.

Con la evaluación perezosa, por el contrario, se retrasa la computación hasta que el resultado es utilizado.

A excepción de los operadores lógicos && y || y el operador ternario, Javascript no soporta la evaluación perezosa. Y eso es un problema, puesto que nuestro código siempre consumira recursos por el total de operaciones que reflejemos en el código.

Sin embargo ésta puede ser implementada de diversas formas. Con los mencionados operadores lógicos por ejemplo —y de una forma muy limitada—, o usando generadores:

language-javascript

⁠function* lazySum(a, b) {
⁠  yield a + b;
⁠}
⁠
⁠let result = lazySum(1, 3); // computation delayed
⁠console.log(result); // not evaluated yet
⁠console.log(result.next().value); // 4

Aquí la suma no se ejecutará cuando llamamos a lazySum, sino cuando usamos el resultado y llamamos next().

Más adelante veremos operaciones en programación funcional que se ejecutan perezosamente.

Conclusión

Esto es todo por hoy. Todos estos conceptos y operaciones son bastante comunes; pero son los cimientos de las operaciones que veremos próximamente. El código del post se puede ejecutar en el Playground de TypeScript, así como en git.antoniodiaz.me.

Si tienes cualquier duda o has encontrado un error no dudes en escribirme a la dirección que figura en el pie.

En nuestro anterior artículo desarrollamos algunos de los elementos básicos de la programación funcional. En él discutimos conceptos como inmutabilidad, puridad o aridad y operaciones como aplicación parcial, currying o composición, todas ellas elementos fundamentales de este paradigma.

En este artículo vamos a apoyarnos en estas operaciones básicas para construir algunas funciones que nos van a ayudar a la hora de procesar datos voluminosos. Pero antes repasemos de nuevo la composición.

Composición de funciones

Cuando describimos la composición de funciones comenzamos con la definición que se da en álgebra:

... proceso de transformar un conjunto secuencial de funciones unarias en otras anidadas, de modo que el resultado de una función se pasará como parámetro a la siguiente.

Esto lo logramos haciendo uso de una función a la que llamamos compose, que se ejecuta de derecha a izquierda:

language-javascript
⁠
⁠⁠const f = (x) => x * 2;
⁠const g = (x) => x * x;
⁠const h = (x) => x + 2;
⁠
const compose = (...fns) => (x) =>
⁠  fns.reduceRight((acc, curr) => curr(acc), x);
⁠
⁠const composed = compose(f, g, h);
⁠const result = composed(3);
⁠console.log(result); // 50

O una función pipe, que se ejecuta de izquierda a derecha:

language-javascript
⁠
⁠⁠const f = (x) => x * 2;
⁠const g = (x) => x * x;
⁠const h = (x) => x + 2;
⁠
const pipe = (...fns) => (x) =>
⁠  fns.reduce((acc, curr) => curr(acc), x);
⁠
⁠const piped = pipe(f, g, h);
⁠const result = piped(3);
⁠console.log(result); // 38

También comentamos que la composición no es conmutativa, f \circ g \neq g \circ f:

⁠language-javascript
⁠
⁠const composedA = compose(f, g);
⁠const composedB = compose(g, f);
⁠
⁠const isCommutative = composedA(3) === composedB(3);
⁠
⁠console.log(isCommutative); // false

Si bien sí es asociativa, f \circ (g \circ h) = (f \circ g) \circ h:

language-javascript
⁠
⁠const composedA = compose(f, compose(g, h));
⁠const composedB = compose(compose(f, g), h);
⁠
⁠const isAssociative = composedA(3) === composedB(3);
⁠
⁠console.log(isAssociative); // true

Nada nuevo, todo esto ya habíamos visto en nuestro anterior artículo. Pero es bueno repasarlo, ya que es fundamental para lo que vamos a tratar a continuación.

Operando con iterables

Hasta ahora hemos visto cómo podemos componer funciones para trabajar con primitivos u objetos; pero hemos obviado el caso de los iterables, como puede ser el caso de Array en Javascript.

Para poder trabajar con ellos tenemos que apoyarnos en algunas utilidades que vamos a implementar a continuación.

Reducers

La primera función que nos va a ayudar a trabajar con iterables es conocida como "reducer: funciones binarias —de aridad 2— que reducen dos valores en un único resultado.

Un reducer sencillo tiene la siguiente forma:

language-javascript
⁠
⁠const accumulate = (a, b) => a + b;
⁠console.log(accumulate(1, 2)); // 3
⁠
⁠const concat = (array, val) => [...array, val];
⁠console.log(concat([1], 2)); // [1, 2]
⁠
⁠const power = (base, exponent) => base ** exponent;
⁠console.log(power(2, 4)); // 16

Aunque también puede hacer merge de dos objetos:

language-javascript
⁠
⁠const merge = (a, b) => ({ ...a, ...b });
⁠console.log(merge({ a: 1 }, { b: 2 })); // { a: 1, b: 2 }

O puede contener una lógica un poco más elaborada: por ejemplo, un reducer que recibe una lista y un valor, el cual es sumado a cada elemento de esa lista:

language-javascript
⁠
⁠const sumEach = (iterable, val) => {
⁠  const result = [];
⁠
⁠  for (const item of iterable) {
⁠    result.push(item + val);
⁠  }
⁠
⁠  return result;
⁠};
⁠
⁠const result = sumEach([1, 2], 3);
⁠console.log(result); // [4, 5]

Esta última función es interesante, pero tiene un problema: hace dos cosas entrelazadas. Por una parte "reduce" los dos valores en uno sólo —dos enteros a un único valor, un array y un entero a otro array, dos objetos a uno sólo, etc.—, y por otra contiene cierta lógica que ejecuta sobre los valores a reducir —sumar un valor a cada item del array—.

Sería perfecto si pudiésemos desacopar ambas tareas.

Podemos empezar extrayendo la parte de la suma, que le pasaríamos como un callback y que a su vez sería un reducer: así podríamos ejecutarlo con el iterable a transformar, que será inicializado con un valor inicial initialValue. Y como nuestra función sumEach ya no tendrá la responsabilidad de la suma, podremos darle un nombre acorde a lo que hace: reduce.

language-javascript
⁠
⁠const reduce = (reducer, iterable, initialValue) => {
⁠  let accumulation = initialValue;
⁠
⁠  for (const item of iterable) {
⁠    accumulation = reducer(accumulation, item);
⁠  }
⁠
⁠  return accumulation;
⁠};
⁠
⁠const data = [1, 2, 3];
⁠const increaseOne = (acc, val) => acc.concat([val + 1]);
⁠const result = reduce(increaseOne, data, []);
⁠console.log(result); // [2, 3, 4]

Aquí ya hemos dado un paso: hemos logrado separar la parte de la operación de suma respecto de la operación de reducción, y albergarla en increaseOne. Y si esta función reduce te suena familiar, es porque es prácticamente idéntica al método Array.reduce de JavaScript.

language-javascript
⁠
⁠const data = [1, 2, 3];
⁠const increaseOne = (acc, val) => acc.concat([val + 1]);
⁠const result = data.reduce(increaseOne, []);
⁠console.log(result); // [2, 3, 4]

Si ahora recordamos nuestra función compose, veremos que está usando Array.reduceRight().

language-javascript
⁠
⁠const compose = (...fns) => (initialData) => 
⁠  fns.reduceRight((acc, curr) => curr(acc), initialData);

Podemos ver qué sucede al reemplazar Array.reduceRight() por nuestro reduce.

language-javascript
⁠
⁠const compose = (...fns) => (initialData) => 
⁠  reduce((acc, curr) => curr(acc), fns.reverse(), initialData);
⁠
⁠const functionA = (value: number) => value + 1;
⁠const functionB = (value: number) => value * 2;
⁠const functionC = (value: number) => value + 3;
⁠
⁠const composed = compose(functionA, functionB, functionC);
⁠const result = composed(1);
⁠
⁠console.log(result); // 9

Funciona perfectamente. Lógico, ya que los tipos de entrada y salida son prácticamente los mismos. Cabe destacar que hemos invertido el array que alberga las funciones a componer con Array.reverse(), ya que compose debe ejectarlas de derecha a izquierda.

Para implementar pipe procederíamos del mismo modo, pero sin invertir el array, ya que las debe ejecutar de izquierda a derecha:

language-javascript
⁠
⁠const pipe = (...fns) => (initialData) => 
⁠  reduce((acc, curr) => curr(acc), fns, initialData);
⁠
⁠const functionA = (value: number) => value + 1;
⁠const functionB = (value: number) => value * 2;
⁠const functionC = (value: number) => value + 3;
⁠
⁠const piped = pipe(functionA, functionB, functionC);
⁠const result = piped(data);
⁠
⁠console.log(result); // 7

Fantástico, ya hemos implementado nuestro propio Array.reduce(), que es agnóstico respecto del reducer que se le pasa, y lo hemos usado en nuestros propios compose y pipe.

Transformers

Ahora que ya tenemos nuestra función reduce podemos avanzar un paso más allá y ver qué son y para qué sirven los "transformers".

Una de las operaciones más comunes que se puede hacer sobre iterables es convertir cada uno de sus elementos de un tipo A a otro tipo diferente B.

Para ello podemos crear una función map que recibirá una función de transformación a la que llamaremos mapper, y que será la encargada de realizar la operación para transformar cada elemento del iterable. Este map creará otra función que admitirá un reducer, y que se encargará de la operación de acumular los elementos del iterable a una estructura de datos determinada —otro array, un objeto, un entero, etc—, pero independientemente de la transformación que se realice sobre cada elemento del iterable. A su vez esta segunda función devolverá otro reducer, el cual aplicará ambas operaciones —la transformación (el mapper) y la acumulación (el reducer)— sobre el iterable que se le pase:

language-javascript
⁠
const map = (mapper) => (reducer) => (acc, value) =>
⁠  reducer(acc, mapper(value));

Suena complicado, pero quedémonos con la idea de que nuestro map, al ser llamado con un mapper, crea una función que tiene una particularidad: recibe un reducer y devuelve otro reducer.

Fijémonos en el siguiente ejemplo: dado un array con enteros, podemos hacer uso de la función map pasándole una función que convertirá el entero que reciba a una cadena de texto. Después volvemos a llamar a esta función pasándole el acumulador a utilizar —devolver un nuevo array con concat— para finalmente pasarle esta última función a reduce y que la utilice.

language-javascript
⁠
⁠const map = (mapper) => (reducer) => (acc, value) =>
⁠  reducer(acc, mapper(value));
⁠
⁠const data = [1, 2, 3];
const integerToString = map((x) => x.toString());
⁠const integerToStringWithReducer = integerToString(concat);
⁠const result = reduce(integerToStringWithReducer, data, []);
⁠
⁠console.log(result); // ["1", "2", "3"]

Y del mismo modo que hemos creado una función map que transforma valores podríamos crear una función similar para seleccionar elementos de un array.

Por ejemplo, en lugar de nuestro map, podemos crear una función filter que recibiese como argumento otra función a la que llamaremos predicate y que evaluase si un elemento dado del array debe o no quedarse en el array. Y al igual que en el map esta segunda función recibirá un acumulador encargado de la operacion reduce a realizar y devolverá otro reducer. La diferencia radica en que en el caso del filter este último reducer aplicará el predicado sobre el valor en cuestión, y si el resultado es true, lo añadirá al array; en caso contrario, lo descartará.

language-javascript
⁠
const filter = (predicate) => (reducer) => (acc, val) => 
⁠  predicate(val) ? reducer(acc, val) : acc;

Esta función filter la podríamos utilizar de un modo muy similar a como hicimos con map.

language-javascript
⁠
const filter = (predicate) => (reducer) => (acc, val) =>
⁠  predicate(val) ? reducer(acc, val) : acc;
⁠
⁠const data = [1, 2, 3];
⁠const isOdd = filter((x) => x % 2 !== 0);
⁠const isOddWithReducer = isOdd(concat);
⁠const result = reduce(isOddWithReducer, data, []);
⁠
⁠console.log(result); // [1, 3]

Al igual que sucedía reduce, podemos ver que filter y map tienen sus análogos nativos en Array.map y Array.filter, produciendo resultados similares. Pero en este caso nuestras funciones tienen una particularidad: pueden componerse.

Por ejemplo, podemos crear sendas funciones que primero seleccionen los valores impares y seguidamente sumen 1 a cada uno de los resultantes con pipe.

language-javascript
⁠
const data = [1, 2, 3, 4, 5];
⁠
⁠const isOdd = filter((x: number) => x % 2 !== 0);
⁠const incrementValue = map((x: number) => x + 1);
⁠
const incrementOddValues = pipe(incrementValue, isOdd);
⁠const incrementValueWithReducer = incrementOddValues(concat);
⁠const result = reduce(incrementValueWithReducer, data, []);
⁠
⁠console.log(result); // [2, 4, 6]

Y al igual que anteriormente, la composición no es conmutativa, de modo que el orden de las funciones importa: si en lugar de pipe —de izquierda a derecha— usamos compose —de derecha a izquierda— vamos a ver un resultado diferente.

language-javascript
⁠
const data = [1, 2, 3, 4, 5];
⁠
⁠const isOdd = filter((x: number) => x % 2 !== 0);
⁠const incrementValue = map((x: number) => x + 1);
⁠
const incrementOddValues = compose(incrementValue, isOdd);
⁠const incrementValueWithReducer = incrementOddValues(concat);
⁠const result = reduce(incrementValueWithReducer, data, []);
⁠
⁠console.log(result); // [3, 5]

Conclusión

Recapitulemos: hemos visto qué son los reducers, qué son los transformers y dos funciones relacionadas con ellos: mappers y filters.

• Reducer: función pura que acepta dos valores y los reduce en un único valor. No se pueden componer, ya que devuelven un valor único, mientras que reciben dos.
• Transformer: función encargada de transformar datos en iterables. Las usamos para crear otro tipo de funciones que se pueden componer con facilidad.
• Mapper: función que acepta otra función como parámetro, la cual convierte datos del tipo A al tipo B usando la función recibida.
• Filter: función que acepta una función predicado —que devuelve booleano—, y crea otra función que usará ese predicado para saber si un elemento del array en cuestión debe mantenerse en el valor devuelto o no.

Es importante tener claros estos conceptos, ya que son la base de lo que vamos a ver a continuación: los transducers.

Esto es todo por hoy. Como siempre, el código se puede ejecutar en el Playground de TypeScript, así como está disponible para descarga en git.antoniodiaz.me.

Si tienes cualquier duda o has encontrado un error no dudes en escribirme a la dirección que figura en el pie.

Desde hace algún tiempo Rust ha estado ganando popularidad entre desarrolladores, siendo el lenguaje más apreciado los últimos cinco años según las estadísticas de stackoverflow. Pero otros índices, como el de Tiobe, lo posicionan por debajo de los veinte lenguajes más usados. Es además dificil encontrar programadores actualmente trabajando con este lenguaje, o empresas utilizándolo en producción.

¿Qué significa todo esto? Mientras que Rust es reconocido como una herramienta de valor por parte de la comunidad de desarrolladores, su integración en la industria está requiriendo tiempo, quizás debido a su especialización y particularidades. ¿Por qué, entonces, invertir tiempo en un lenguaje así? ¿Cómo pinta el futuro de Rust? Para responder a todas estas cuestiones echaremos un vistazo al lenguaje, su sintaxis, sus funcionalidades fundamentales y cómo puede ser utilizado para aplicaciones web básicas.

Características

Rust se originó en el equipo de Mozilla como el proyecto personal de uno de sus desarrolladores, Graydon Hoare. Desde entonces ha evolucionado hasta convertirse en un proyecto soportado por una amplia comunidad de programadores, con la Rust Foundation como sus principal órgano de gobierno.

Tiene algunas características que, juntas, lo hacen diferente a otros lenguajes:

• Es un lenguaje compilado.
• Es de tipado fuerte, con tipado nominativo para structs y estructural para tuplas.
• Carece de recolector de basura, usando un «verificador de préstamos» —«borrow checker»— en su lugar.
• Provee de punteros/referencias para el stack, y punteros avanzados para el heap.
• Está concebido tanto para OOP como para programación funcional.
• As agnóstico respecto del entorno de ejecución asíncrono que se use.
• Tiene una suite de tests integrada en el lenguaje.

Veamos cada punto para ver qué puede ofrecernos cada característica.

Siendo un lenguaje compilado, Rust nos ofrecerá gran cantidad de información sobre el uso de memoria de nuestro programa antes de la ejecución del mismo. Haciendo uso de estructuras fuertemente tipadas Rust garantiza que, una vez que el programa compila, es seguro en cuanto a uso de memoria. Es importante mencionar que usa tipado nominativo para structs y estructural para tuplas: esto quiere decir que dos instancias de structs diferentes tendrán diferente tipo para el compilador incluso cuando esos structs tengan una forma idéntica; lo contrario sucede con las tuplas: dos tuplas tendrán el mismo tipo siempre que tengan la misma forma.

Por supuesto, nosotros los programadores podremos cometer errores de muchas otras maneras, especialmente en cuanto a lógica de negocio se refiere; pero el compilador nos asegura que, estructuralmente, nuestro programa será tan eficiente y coherente como sea posible.

Esto sucede principalmente por el hecho de que Rust no depende de un sistema de recolección de basura. Lenguajes como Java, Python o Javascript dependen de un recolector de basura para manejar la memoria y eliminar variables que quedan en desuso. En otros lenguajes, como C o C++, se requiere manejar los recursos manualmente; pero en Rust tenemos un «comprobador de préstamos», esto es, un sistema que se asegura en tiempo de ejecución que cuando una variable queda fuera de uso, esta es eliminada.

Esta funcionalidad es automática para todos los valores cuyo tamaño sea conocido de antemano, almacenándose en el stack. Podemos hacer además uso de punteros al estilo C —(*&)— para referenciarlos y deferenciarlos; siempre con algunos límites impuestos por Rust para evitar acciones inseguras con la memoria.

Para aquellos otros valores cuyo tamaño no es conocido de antemano por el compilador, y que tienen que ser almacenaos en el heap, como por ejemplo los arrays —«vectores» en Rust—, el lenguaje nos ofrecerá estructuras específicas —Box, Rc, Arc, etc.—para envolverlos y asegurar que serán elminados lo más pronto posible.

Una de las principales funcionalidades de Rust es el retorno a una versión simplificada de las estructuras al estilo C, en oposición a las clases a las que lenguajes como C++ o Java nos tienen acostumbrados. Aquí encontraremos tres términos clave relacionados con estas estructuras: struct, impl y trait. Podemos definir un nuevo struct con struct; después de definirlo, podemos añadirle métodos usando impl. Finalmente, en caso que queramos describir un comportamiento común para structs diferentes podremos hacer uso de trait, que viene a ser algo similar a lo que en otros lenguajes se denominan «interfaces». Todo esto se vé más claro con un ejemplo:

language-rust
⁠
⁠// Podemos definir un struct para Persona
⁠//  con un nombre que podrá ser un String
⁠struct Persona {
  nombre: String,
⁠}
⁠
⁠// Igualmente podemos definir un struc para Gato
⁠//  también con un nombre String
⁠struct Gato {
  nombre: String,
⁠}
⁠
⁠// Cada ser vivo puede realizar ciertas acciones.
⁠//  Por ejemplo, presentarse
⁠trait SerVivoAcciones {
  fn presentarse(&self);
⁠}
⁠
⁠// La persona puede presentarse verbalmente
⁠impl SerVivoAcciones for Persona {
  fn presentarse(&self) {
    println!("- {}: Hola! Es un placer :)", &self.nombre);
  }
⁠}
⁠
⁠// El gato también puede presentarse, pero… al estilo gatuno
⁠impl SerVivoAcciones for Gato {
  fn presentarse(&self) {
    println!("- {}: Mrrrrr… Miaaou", &self.nombre);
  }
⁠}
⁠
⁠// Podemos instanciar una Persona y un Gato
⁠//  y hacer que se presenten
⁠fn main() {
  let fulanito = Persona {
    nombre: String::from("Fulanito"),
  };
  let minino = Gato {
    nombre: String::from("Minino"),
  };
  fulanito.presentarse(); // - Fulanito: Hola! Es un placer :)
  minino.presentarse(); // - Minino: Mrrrrr… Miaaou
⁠}

Este uso de structs en lugar de clases evita que escribamos estructuras muy anidadas, favoreciendo la composicion de elementos sobre las herencias. Rust nos permitirá escribir código tanto orientado a objetos como funcional, pero con ciertos límites en ambos casos. Es perfectamente posible usar patrones clásicos de programación orientada a objetos como la inyección de dependencias o funcionalidades como el polimorfismo, así como también lo es escribir código funcional con clausuras sin mutación de estado. Ambas aproximaciones encajan con naturalidad, aunque con algunas restricciones que nos inducirán a escribir estructuras más atómicas y legibles. El código resultante tendrá una sintaxis algo más compleja que en otros lenguajes, pero con estructuras planas y sencillas que, al final, harán el código más fácil de leer y entender.

Rust se distribuye con una librería estándar que provee de diferentes funcionalidades. Entre ellas se encuentran las herramientas de threading, que nos permiten escribir programas concurrents. Esto, con la ayuda del compilador, el tipado estático, el verificador de préstamos y los punteros avanzados nos asegurarán que nuestros programas concurrentes serán seuros en cuanto a memoria se refiere, incluso en caso de multi-threading.

Una funcionalidad interesante de Rust es que no trae un tiempo de ejecución asíncrono integrado. Para disponer de uno vamos a tener que elegir e instalar uno externo: una opción bastante popular es Tokio, que se puede encontrar en el repositorio oficial de Rust, aunque tenemos más opciones entre las que elegir.

Los tests se escriben con la suite que Rust trae integrada. Es posible escribir tanto tests unitarios para cada módulo como tests de integraciíon para toda la aplicación. Tiene unas funcionalidades muy concretas, pero muy claras y coherentes con la filosofía del lenguaje.

Trabajando con Rust viniendo de lenguajes tipo Java puede generar algo de confusión, pues hay un cambio de paradigma considerable; sin embargo, una vez que esta primera fase es superada, el lenguaje se escribe con asombrosa naturalidad. Tiene similitudes con C y C++, pero con una sintaxis muchísimo más limpia. Dadas las herramientas que nos ofrece para manejo de memoria y genéricos bien se podría describir Rust como «una versión declarativa de C».

Rust en práctica

Para demostrar cómo se podría estructurar un progama en Rust podemos vamos a crear una aplicación sencilla, simplemente para visualizar la sintaxis del lenguaje.

Podríamos, por ejemplo, escribir un programa al que pudieramos pedir una lista de usuarios que estuviera almacenada en algún tipo de base de datos, digamos que en PostgreSQL. Y además, queremos que nos dé esta lista en sentido inverso al que está en la base de datos.

De este modo nuestro programa tendría varios conceptos, a saber:

• Un usuario User, que sería el modelo: un struct.
• El proceso de invertir la lista, que correspondería a la lógica de negocio: esto sería un «caso de uso», que podríamos escribir en un struct. Este caso de uso utilizará el módulo que escribamos para recoger los datos de la base de datos, el cual tendrá que cumplir con un trait que vamos a describir en el siguiente punto.
• Y finalmente, el sistema para recoger los datos de la base de datos en PostgreSQL, que será otro struct. Para evitar acoplar el caso de uso con el repositorio de PostgreSQL escribiremos un trait con la descripción general de nuestro struct para la base de datos, y que le pasaremos al caso de uso. Así, cualquier repositorio que queramos utilizar con nuestro caso de uso tendrá que cumplir con el trait, desacoplando el caso del uso del repositorio y haciendo más fácil cambiar de PostgreSQL a otro tipo de base de datos en el futuro.

Ahora que nos hemos hecho una idea de cómo deberíaser nuestra aplicación, vamos a implementarla. Omitiremos alguna línea de código necesaria para que nuestro programa complile, pero el ejemplo completo se puede ver en el playground de Rust.

Primero, vamos a crear nuestra entidad o modelo: un usuario User con un campo id:

language-rust
⁠
⁠pub struct User {
  pub id: i8,
⁠}

Ahora que tenemos nuestro modelo principal —un struct—, la siguiente cuestión es qué queremos hacer con él. En otras palabras: queremos definir el caso de uso para recoger la lista de usuarios en sentido inverso. Sabemos que este caso de uso tendrá que tener una instancia del repositorio para recoger los datos de la base de datos, pero no sabemos todavía el tipo del repositorio: esto es una tarea para un tipo genérico:

language-rust
⁠
⁠struct GetUsersRevertedUseCase<T> {
  repository: T,
⁠}

Nuestro caso de uso —también un struct— infiere el tipo del repositorio cuando se la pasamos al instanciarlo. Pero un struct no define acciones, y nuestro caso de uso precisamente tiene que realizar las acciones definidas por la lógica de negocio de nuestro programa. Como decíamos anteriormente, esto lo haremos implementando los métodos necesarios con el término impl:

language-rust
⁠
⁠impl<T: Repository> GetUsersRevertedUseCase<T> {
  fn new(repository: T) -> GetUsersRevertedUseCase<T> {
    GetUsersRevertedUseCase { repository }
  }
⁠}

Digno de mención aquí es la sintaxis <T: Repository>. Con esto le estamos diciendo al compliador que T puede ser cualquier struct implementando el trait Repository, devolviendo un error si pasamos cualquier otro tipo de instancia. Además, hemos añadido un método new que devuelve una instancia de sí mismo pero con la instancia del repositorio en su interior. Así que ya tenemos nuestro caso de uso con la capacidad de recibir un repositorio, siempre que este cumpla con los requerimientos de un determinado trait, el cual tenemos pendiente.

Veamos cómo podemos definir el tipo de repositorio que necesitamos. Sabemos que tiene que realizar una acción asíncrona —recoger datos de una base de datos—, y que tiene que devolver los datos que ha recibido —una lista de usuarios—. Podemos escribir un trait con estas especificaciones de la siguiente manera:

language-rust
⁠
⁠trait Repository {
  async fn get_users(&self) -> Result<Vec<User>, String>;
⁠}

Hay algunas cosas nuevas aquí: primero, el término async, el cual hace que nuestra fución devuelva un tipo Result. Este tipo es una de las particularidades de Rust: representa el resultado de una acción que puede tener éxito —Ok(T)— o sufrir un error —Err(K)—. En nuestro caso, si la acción definida por nuestro método tiene éxito, tendrá como resultado Ok<Vec<User>>, esto es, una lista de ususarios User; por el contrario, si nuestra acción fracasa, devolverá Err(String). Para no liarnos mucho no vamos a implementar ningún error, pero el tipo Result nos obliga a tener esta posibilidad en consideración, puesto que estamos escribiendo código asíncrono. Esto es una de las ventajas de Rust: no nos deja ser perezosos con los tipos.

Ahora podemos pensar en cómo podemos lanzar nuestro caso de uso, para lo cual podemos añadirle un método execute.

language-rust
⁠
⁠impl<T: Repository> GetUsersRevertedUseCase<T> {
  […]
  async fn execute(&self) -> Result<Vec<User>, String> {
    let users = self.repository.get_users().await.unwrap();
    let reverted_users: Vec<User> = users.into_iter().rev().collect();
    Ok(reverted_users)
  }
⁠}

Ah, el término async otra vez, esta vez para esperar a que la acción de nuestro repositorio termine. También está el tipo Result, esto empieza a ser familiar.

Como nuestro repositorio está devolviendo un tipo Result —Ok<T> o Err<K>—, necesitamos extraer el valor —la lista de usuarios— de nuestro Ok<T> para trabajar con ella. Esto lo hacemos con la función unwrap(), que nos devuelve el valor T —nuestra lista de usuarios— si estamos en un Ok, o devolviendo un error si fracasa.

Además tenemos algunas funciones operando sobre nuestra lista de usuarios para invertirla: into_iter, que convierte un vector en una lista de elementos que podamos iterar; rev, que invierte una lista de elementos iterable, y collect, que convierte una lista iterable de nuevo en un vector. Estas funcionalidades pertenecen todas al tipo Vec, que está integrado en Rust para manipular vectores al estilo funcional.

Vale, ahora ya tenemos nuestro modelo, nuestro caso de uso, y un trait para cualquier repositorio que queramos pasarle. El siguiente paso será crear nuestro repositorio para el tipo concreto de base de datos que queramos utilizar: PostgreSQL:

language-rust
⁠
⁠impl Repository for PostgreSQLRepository {
  async fn get_users(&self) -> Result<Vec<User>, String> {
⁠    let duration_secs = Duration::from_secs(2);
⁠    sleep(duration_secs);
⁠    let user_1 = User { id: 1 };
⁠    let user_2 = User { id: 2 };
⁠    Ok(vec![user_1, user_2])
⁠  }
⁠}

Como esto es sólo una demostración simplemente vamos a simular que vamos a recoger datos de manera asíncrona de nuestra supuesta base de datos. Para ello usaremos dos métodos de la librería estándar: sleep y Duration. Duration devuelve un tipo específico de tiempo, que le podremos pasar a otros métodos, como por ejemplo sleep. Y sleep simplemente detendrá la ejecución del programa por el tiempo que le hayamos pasado. En nuestro caso estamos deteniendo nuestro programa por dos segundos, entonces instanciamos dos usuarios, y finalmente estamos devolviendo un Vector con ellos.

Ahora disponemos ya de todos los elementos necesarios para nuestro programa: el modelo User, el caso de uso GetUsersRevertedUseCase, el trait Repository y el struct PostgreSQLRepository que lo implementa. Sólo nos falta crear un punto de entrada para nuestro programa y hacer uso de ellos.

language-rust
⁠
⁠#[tokio::main]
⁠async fn main() {
⁠  let repository = PostgreSQLRepository;
⁠  let use_case = GetUsersRevertedUseCase::new(repository);
⁠  let users = use_case.execute().await.unwrap();
⁠  println!("{:#?}", users);
⁠}

Como queremos ejecutar código asíncrono necesitaremos traer un tiempo de ejecución que nos lo facilite: vamos a usar Tokio, así que podemos llamar al macro #[tokio:main].

Después no tenemos más que crear una instancia de nuestro repositorio, construir nuestro caso de uso pasándole la instancia que acabamos de crear, y ejecutarla, esperándola con await. El resultado será una lista de usuarios en sentido inverso.

language-rust
⁠
⁠[
⁠  User {
⁠    id: 2,
⁠  },
⁠  User {
⁠    id: 1,
⁠  },
⁠]

Podemos ver este código completo en el playground de Rust, donde podemos compilarlo y ejecutarlo.

Conclusión

Rust no es un lenguaje sencillo. Exige estudio y bastante paciencia para entender su sintaxis y las funcionalidades que nos ofrece. Además es muy joven, y su ecositema está en constante evolución. Pero promete.

Es en tareas que requieren eficiencia donde el lenguaje encaja perfectamente. Para desarrollo web en términos generales, donde la velocidad de prototipado y se requieren dinámicas de trabajo agile son importantes, lenguajes interpretados como Python o TypeScript encajan mejor. Pero cuando pérdidas de memoria puedan provocar repuntes o problemas de eficiencia en uso de servidores, Rust es una opción mucho mejor.

La aceptación actual de Rust en la industria es muy limitada, pero la Rust Foundatio es soportada por Google, Microsoft, AWS, Huawei y Mozilla; además hay una clara demanda para lenguajes enfocados a eficiencia, y probablemente veremos cómo logra introducirse en los próximos años.

En cualquier caso hay numerosas dificultades: las empresas que dan soporte a Rust intentarán influenciar sobre su desarrollo  para que evolucione según sus necesidades particulares, y hay claros desacuerdos entre el equipo interno. Pero el lenguaje encaja tan bien en las tareas que hemos mencionado que sería interesante seguir su evolución e integración en la industria.

Para concluir: Rust es un lenguaje complejo, pero es posible y claramente deseable usar Rust en contextos específicos donde performance y seguridad es un requerimiento.

Algunas notas acerca del algoritmo de Ordenamiento por Mezcla.

Descripción

Algoritmo recursivo fundamentado en la estrategia «divide y vencerás». Dos componentes principales:

• Una función para separar listas recursivamente hasta que recibe un único elemento.
• Una función que combina dos elementos ya ordenados en una lista ordenada.

Complejidad temporal

Pseudocódigo

Implementación en Rust

language-rust
⁠
⁠pub fn merge_sorted_arrays(left: Vec<i32>, right: Vec<i32>) -> Vec<i32> {
⁠  let left_length = left.len();
⁠  let right_length = right.len();
⁠
⁠  // El array resultante tendrá el tamaño de los dos arrays que se pasen
⁠  let mut sorted_items = vec![0; left_length + right_length];
⁠
⁠  let mut i = 0;
⁠  let mut j = 0;
⁠
⁠  // Iterar sobre el array que vamos a rellenarcon elementos de los arrays 
⁠  // izquierdo o derecho
⁠  for k in 0..sorted_items.len() {
⁠    // Si ninguno de los punteros "i" ni "j" han llegado a su límite
⁠    if i + 1 <= left.len() && j + 1 <= right.len() {
⁠      // Decidir entre el elemento actual del array izquierdo 
⁠      // y el elemento actual del array derecho cuál de los dos será 
⁠      // el siguiente para el array final
⁠      if left[i] <= right[j] {
⁠        sorted_items[k] = left[i];
⁠        i = i + 1;
⁠      } else if left[i] > right[j] {
⁠        sorted_items[k] = right[j];
⁠        j = j + 1;
⁠      }
⁠    } else if i + 1 <= left.len() {
⁠      // Si sólo el puntero "i" no ha alcanzado el límite 
⁠      // —y por tanto "j" lo ha hecho—
⁠      sorted_items[k] = left[i];
⁠      i = i + 1;
⁠    } else if j + 1 <= right.len() {
⁠      // Si sólo el puntero "j" no ha alcanzado el límite 
⁠      // —y por tanto "i" lo ha hecho—
⁠      sorted_items[k] = right[j];
⁠      j = j + 1;
⁠    }
⁠  }
⁠
⁠  sorted_items
⁠}
⁠
⁠pub fn sort_array(unsorted_array: &Vec<i32>) -> Vec<i32> {
⁠  let n = unsorted_array.len();
⁠  if n <= 1 {
⁠    // Caso base: si el input es de longitud 1, 
⁠    // entonces está ya ordenado: devolverlo
⁠    let sorted_array = unsorted_array.to_vec();
⁠    sorted_array
⁠  } else {
⁠    // Si el input es de longitudo dos o mayor
⁠    // 1. Separarlo
⁠    let (left, right) = unsorted_array.split_at(n / 2);
⁠    let left_vec = left.to_vec();
⁠    let right_vec = right.to_vec();
⁠
⁠    // 2. Ordenarlo recursivamente
⁠    let left_sorted = sort_array(&left_vec);
⁠    let right_sorted = sort_array(&right_vec);
⁠    let sorted_array_1 = merge_sorted_arrays(left_sorted, right_sorted);
⁠    sorted_array_1
⁠  }
⁠}
⁠
⁠fn main() {
⁠  let unsorted_array: Vec<i32> = vec![2, 1, 4, 3];
⁠  let sorted_array = sort_array(&unsorted_array);
⁠  println!("unsorted_array: {:?}", unsorted_array);
⁠  println!("sorted_array: {:?}", sorted_array);
⁠}
⁠
⁠#[cfg(test)]
⁠mod tests {
⁠  use super::*;
⁠
⁠  #[test]
⁠  fn works_with_sorted_arrays() {
⁠    let unsorted_array = vec![1, 2];
⁠    let sorted_array = sort_array(&unsorted_array);
⁠    let expected_result = vec![1, 2];
⁠    assert_eq!(expected_result, sorted_array);
⁠  }
⁠
⁠  #[test]
⁠  fn works_with_simple_unsorted_array() {
⁠    let unsorted_array = vec![2, 1];
⁠    let sorted_array = sort_array(&unsorted_array);
⁠    let expected_result = vec![1, 2];
⁠    assert_eq!(expected_result, sorted_array);
⁠  }
⁠
⁠  #[test]
⁠  fn works_with_simple_uneven_lenght_arrays() {
⁠    let unsorted_array = vec![2, 1, 3];
⁠    let sorted_array = sort_array(&unsorted_array);
⁠    let expected_result = vec![1, 2, 3];
⁠    assert_eq!(expected_result, sorted_array);
⁠  }
⁠
⁠  #[test]
⁠  fn it_works_with_sorted_arrays() {
⁠    let left = vec![1, 2];
⁠    let right = vec![3, 4];
⁠    let merged = merge_sorted_arrays(left, right);
⁠    let expected_result = vec![1, 2, 3, 4];
⁠    assert_eq!(expected_result, merged);
⁠  }
⁠
⁠  #[test]
⁠  fn it_works_with_splits() {
⁠    let left = vec![3, 4];
⁠    let right = vec![1, 2];
⁠    let merged = merge_sorted_arrays(left, right);
⁠    let expected_result = vec![1, 2, 3, 4];
⁠    assert_eq!(expected_result, merged);
⁠  }
⁠
⁠  #[test]
⁠  fn it_works_with_uneven_length_lists() {
⁠    let left = vec![3, 4, 5];
⁠    let right = vec![1, 2];
⁠    let merged = merge_sorted_arrays(left, right);
⁠    let expected_result = vec![1, 2, 3, 4, 5];
⁠    assert_eq!(expected_result, merged);
⁠  }
⁠
⁠  #[test]
⁠  fn it_works_with_single_item_lists() {
⁠    let left = vec![3];
⁠    let right = vec![1];
⁠    let merged = merge_sorted_arrays(left, right);
⁠    let expected_result = vec![1, 3];
⁠    assert_eq!(expected_result, merged);
⁠  }
⁠}

When I went through the exercises on The Rust Programming Language book I remember finding the example about closures interesting. The provided code was just about implementing a naive cache system to avoid repeated expensive calculations for previously passed inputs. It looked like this:

language-rust
⁠
// Struct accepting a Generic, which has 
⁠// to be a function with an u32 as parameter
⁠// and returning an u32 value
⁠pub struct Cacher<T: Fn(u32) -> u32> {
⁠  pub calculation: T,
⁠  pub value: Option<u32>,
⁠}
⁠
⁠// Implementation for Cacher, where we add our behaviour
⁠impl<T: Fn(u32) -> u32> Cacher<T> {
⁠  // Instantiate the struct with a function, that will be
⁠  // stored within the struct scope as a closure
⁠  pub fn new(calculation: T) -> Cacher<T> {
⁠    Cacher {
⁠      calculation,
⁠      value: None,
⁠    }
⁠  }
⁠
⁠  // Getter to retrieve the current value
⁠  pub fn value(&mut self, input: u32) -> u32 {
⁠    match self.value {
⁠      Some(value) => value,
⁠      None => {
⁠        let value = (self.calculation)(input);
⁠        self.value = Some(value);

⁠⁠        value
⁠      }
⁠    }
⁠  }
⁠}
⁠

Easy enough. If value is empty the cacher will calculate the result and return it; otherwise, it will return the existing value. But there is a catch: if we run the Cacher::value() method twice with different values, it will return the first one that was stored, which we can demonstrate with this test:

language-rust
⁠
#[cfg(test)]
⁠mod tests {
⁠  use super::*;
⁠  use ::std::thread;
⁠  use ::std::time::Duration;
⁠
⁠  #[test]
⁠  fn call_with_different_values() {
⁠    fn my_function(num: u32) -> u32 {
⁠   ⁠   num
⁠    }
⁠
⁠    let mut cacher = Cacher::new(my_function);
⁠
⁠    let value_1 = cacher.value(1);
⁠    let value_2 = cacher.value(2);
⁠
⁠    assert_eq!(value_1, 1);
⁠    assert_eq!(value_2, 2);
⁠  }
⁠}

The issue is that we are storing the value within Cacher.value directly, so once it is calculated the same value will be returned the rest of the times. What we need is a structure that can store the resulting values in relation to the inputs, and one with fast search and insert times. We need a Hashmap.

So instead of using value as an Option<u32> to store a single value, we can use values with an std::collections::HashMap, as follows:

language-rust
⁠
use std::collections::HashMap; 
⁠
⁠struct Cacher<T: Fn(u32) -> u32> {
⁠  calculation: T,
⁠  values: HashMap<u32, u32>,
⁠}

Our hashmap will have u32 keys with u32 values. We can now proceed to instantiate it on our constructor:

language-rust
⁠
fn new(calculation: T) -> Cacher<T> {
⁠  Cacher {
⁠    calculation,
⁠    values: HashMap::new(),
⁠  }
⁠}

And finally create or getter/setter method with the match pattern that will decide what to do:

language-rust
⁠
fn value(&mut self, input: u32) -> u32 {
⁠  match self.values.get(&input) {
⁠    Some(value) => *value,
⁠    None => {
⁠      let value = (self.calculation)(input);
⁠      self.values.insert(input, value);
⁠
⁠      value
⁠    }
⁠  }
⁠}

So if the input already exists in self.values —self.values.get(&input)—, retrieve it; otherwise, set into self.values both the input and value as key/value pair. Notice that when a given value exists —Some(value)—, we retrieve it as *value: that's because what we store is the reference &input, so we need to dereference it to retrieve its actual value. If we remove the dereference we will get the corresponding error notifying that Rust expected `u32`, found `&u32`.

language-none
⁠
⁠⣿ Standard Error
⁠
⁠Compiling playground v0.0.1 (/playground)
⁠error[E0308]: mismatched types
⁠  --> src/lib.rs:18:28
⁠   |
⁠16 |     pub fn value(&mut self, input: u32) -> u32 {
⁠   |                    --- expected `u32` because of return type
⁠17 |         match self.values.get(&input) {
⁠18 |             Some(value) => value,
⁠   |                            ^^^^^ expected `u32`, found `&u32`
⁠   |
⁠help: consider dereferencing the borrow
⁠   |
⁠18 |             Some(value) => *value,
⁠   |                            +

Finally note the parenthesis on (self.calculation)(input). They seem unnecesary, but actually they are. Lets break things first and remove them:

language-none
⁠
⣿ Standard Error
⁠
Compiling playground v0.0.1 (/playground)
⁠error[E0599]: no method named `calculation` found for mutable reference 
⁠`&mut Cacher<T>` in the current scope
⁠  --> src/lib.rs:20:34
⁠   |
⁠20 |                 let value = self.calculation(input);
⁠   |                                  ^^^^^^^^^^^ field, not a method
⁠   |
⁠help: to call the function stored in `calculation`, surround the field access 
⁠with parentheses
⁠   |
⁠20 |                 let value = (self.calculation)(input);
⁠   |                             +                +

As previously, Rust informs us both about the error and possible fix. It is intelligent enough to identify that we are trying to call the function we stored as a closure, thus the need of the parenthesis. If we restore them and try to run our test again, this what we get:

language-none
⁠
running 1 test
⁠test tests::call_with_different_values ... ok

Fantastic, it is passing \(^O^)/.
⁠
⁠Of course this is something really simple, but I like the example because it has a reference and a dereference, a structure from std , a closure, a generic with a bound type and a match pattern. You can't ask for more!
⁠

Dado un struct MyStruct, contenido en el módulo my_struct, y un trait Feature contenido en el módulo my_feature, se requiere que MyStruct pueda recibir diferentes implementaciones del trait Feature sin depender directamente de ellas.

Nuestro objetivo será poder indicarle al struct MyStruct que puede recibir mediante el método new() cualquier struct que implemente Feature.
En otros lenguajes —mayormente aquellos con tipado estructural—, la huella de new() tendría esta forma:

language-rust
⁠
⁠fn new(feature: Feature) -> MyStruct;

Esto no funcionará en Rust, pues el compilador no podrá inferir el tamaño del tipo Feature en tiempo de compilación.

Sin embargo, esto puede ser logrado mediante dos estrategia diferentes:

• Usando genéricos
• Usando trait objects

Inversión de dependencias con genéricos

Es posible pasar el tipo concreto de la implementación de Feature como un genérico.

Un primer paso sería definir el trait Feature en el módulo feature:

⁠language-rust
⁠
mod feature {
⁠  pub trait Feature {
⁠    fn action(&self) -> String;
⁠  }
⁠}

Dentro del módulo my_struct se encontraría el struct MyStruct, que recibiría como genérico un tipo que implementa Feature, lo que podemos ver en impl <T: Feature>....

MyStruct recibirá entonces T como genérico, con lo que será posible tipar el parámetro feature como T.

language-rust
⁠
⁠mod my_struct {
⁠  use super::feature::Feature;
⁠
⁠  pub struct MyStruct<T> {
⁠    feature: T,
⁠  }
⁠
⁠  impl<T: Feature> MyStruct<T> {
⁠    pub fn new(feature: T) -> MyStruct<T> {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    pub fn action(&self) -> String {
⁠      self.feature.action()
⁠    }
⁠  }
⁠}

Las diferentes implementaciones de Feature se encontrarían en módulos separados:

language-rust
⁠
mod feature_implementation01 {
⁠  use super::feature::Feature;
⁠
⁠  pub struct FeatureImplementation01;
⁠
⁠  impl Feature for FeatureImplementation01 {
⁠    fn action(&self) -> String {
⁠      String::from("Feature 01 - with generics")
⁠    }
⁠  }
⁠}
⁠

language-rust
⁠
⁠mod feature_implementation02 {
⁠  use super::feature::Feature;
⁠
⁠  pub struct FeatureImplementation02;
⁠
⁠  impl Feature for FeatureImplementation02 {
⁠    fn action(&self) -> String {
⁠      String::from("Feature 02 - with generics")
⁠    }
⁠  }
⁠}

Finalmente, el código cliente consumiría esta lógica:

language-rust
⁠
⁠pub fn main() {
⁠  use feature_implementation01::FeatureImplementation01;
⁠  use feature_implementation02::FeatureImplementation02;
⁠  use my_struct::MyStruct;
⁠
⁠  let feature_implementation_01_instance = FeatureImplementation01;
⁠  // If required, it is possible to pass the type of 
⁠  // the implementation into the generic with turbofish syntax
⁠  let my_struct = 
⁠    MyStruct::<FeatureImplementation01>::new(
⁠      feature_implementation_01_instance
⁠    );
⁠  let result = my_struct.action();
⁠  println!("{:#?}", result);
⁠
⁠  ⁠// If required, it is possible to pass the type of 
⁠  // the implementation into the generic with turbofish syntax
⁠  let feature_implementation_02_instance = FeatureImplementation02;
⁠  let my_struct = 
⁠    MyStruct::<FeatureImplementation01>::new(
⁠      feature_implementation_02_instance
⁠    );
⁠  let result = my_struct.action();
⁠  println!("{:#?}", result);
⁠}

Es importante notar que cuandoMyStruct::new es llamado, está recibiendo el tipo del struct implementando Feature mediante la sintaxis Turbofish.

language-rust
⁠
let my_struct = 
⁠    MyStruct::<FeatureImplementation01>::new(
⁠      feature_implementation_01_instance
⁠    );

El compilador podría ser capaz de inferir este tipo en numerosas ocasiones: ésta es una de ellas, si se elimina el código compilará sin problema. Sin embargo no siempre es éste el caso, y el desarrollador estará forzado a marcarlo manualmente en numerosos casos.

Con trait objects

Rust expone numerosos smart pointers para estructuras con tamaño dinámico: la elección más obvia aquí sería Box.
Los cambios requeridos para conseguir compilar tendrán lugar únicamente en el módulo my_struct, así como en el código cliente.

En primer lugar necesitamos eliminar los genéricos de MyStruct; el problema entonces será que feature tiene el tipo del trait Feature, cuyo tamaño es desconocido en tiempo de compilación, puesto que los structs implementando este trait podrían tener tamaños diversos.

Se puede solu⁠cionar este problema envolviendo Feature dentro de un Box<dyn Feature>⁠, diciéndole así al compilador que envié este struct al heap, siendo así redimensionado dinámicamente.

Para ser más explícito con ello Rust fuerza al desarrollador a marcar con el término dyn todos aquellos objetos que usen dispatch dinámico.

language-rust
⁠
mod my_struct {
⁠  use super::feature::Feature;
⁠
⁠  pub struct MyStruct {
⁠    feature: Box<dyn Feature>,
⁠  }
⁠
⁠  impl MyStruct {
⁠    pub fn new(feature: Box<dyn Feature>) -> MyStruct {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    pub fn action(&self) -> String {
⁠      self.feature.action()
⁠    }
⁠  }
⁠}

El código cliente cambiará igualmente, pues requiere que envolvamos la instancia implementando Feature dentro de una instancia de Box:

language-rust
⁠
fn main() {
⁠  use feature_implementation01::FeatureImplementation01;
⁠  use feature_implementation02::FeatureImplementation02;
⁠  use my_struct::MyStruct;
⁠
⁠  let feature_implementation_01_instance = FeatureImplementation01;
⁠  let my_struct = MyStruct::new(Box::new(feature_implementation_01_instance));
⁠  let result = my_struct.action();
⁠  println!("{:#?}", result);
⁠
⁠  let feature_implementation_02_instance = FeatureImplementation02;
⁠  let my_struct = MyStruct::new(Box::new(feature_implementation_02_instance));
⁠  let result = my_struct.action();
⁠  println!("{:#?}", result);
⁠}

De esta forma el código compila y se ejecuta sin problemas.

Otro caso que se puede encontrar es que MyStruct haga uso de un servicio MyService, que a su vez requerirá contener una instancia de Feature dentro de sí.

language-rust
⁠
mod my_service {
⁠  use super::feature::Feature;
⁠
⁠  pub struct MyService {
⁠    feature: Box<dyn Feature>,
⁠  }
⁠
⁠  impl MyService {
⁠    pub fn new(feature: Box<dyn Feature>) -> MyService {
⁠      MyService { feature }
⁠    }
⁠  }
⁠}

language-rust
⁠
mod my_struct {
⁠  use super::feature::Feature;
⁠  use super::my_service::MyService;
⁠
⁠  pub struct MyStruct {
⁠    feature: Box<dyn Feature>,
⁠  }
⁠
⁠  impl MyStruct {
⁠    pub fn new(feature: Box<dyn Feature>) -> MyStruct {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    pub fn action(self) -> String {
⁠      let my_service = MyService::new(self.feature);
⁠      println!("{}", my_service.action());
⁠
⁠      self.feature.action().to_owned()
⁠    }
⁠  }
⁠}

Ahora el compilador devuelve error, puesto que MyService está siendo transferido a self.feature:

language-rust
⁠
⁠⁠error[E0382]: borrow of moved value: `self.feature`
⁠  --> src/with_box.rs:25:7
⁠   |
⁠21 |       let my_service = MyService::new(self.feature);
⁠   |                                       ------------ value moved here
⁠...
⁠25 |       self.feature.action().to_owned()
⁠   |       ^^^^^^^^^^^^^^^^^^^^^ value borrowed here after move

Cuando pasamos self.feature a MyService aquel es consumido, y no estará disponible tras esa acción. Una solución podría ser clonarlo con clone(), pero el compilador devolverá un nuevo error:

language-rust
⁠
error[E0599]: the method `clone` exists for struct 
⁠   `Box<(dyn with_box::feature::Feature + 'static)>`, 
⁠   but its trait bounds were not satisfied
⁠   --> src/with_box.rs:21:52
⁠    |
⁠2   |     pub trait Feature {
⁠    |     -----------------
⁠    |     |
⁠    |     doesn't satisfy `dyn with_box::feature::Feature: Clone`
⁠    |     doesn't satisfy `dyn with_box::feature::Feature: Sized`
⁠...
⁠21  |         let my_service = MyService::new(self.feature.clone());
⁠    |                                                      ^^^^^ method 
⁠                cannot be called on 
⁠                `Box<(dyn with_box::feature::Feature + 'static)>` 
⁠                due to unsatisfied trait bounds

El trait Box no implementa Clone. Podría hacerse una implementación ad hoc de Clone para Box<dyn Feature>, pero hay una solución más sencilla para este caso: usar el puntero Rc en lugar de Box.

language-rust
⁠
⁠mod my_struct {
⁠  use super::feature::Feature;
⁠  use super::my_service::MyService;
⁠  use std::rc::Rc;
⁠
⁠  pub struct MyStruct {
⁠    feature: Rc<dyn Feature>,
⁠  }
⁠
⁠  impl MyStruct {
⁠    pub fn new(feature: Rc<dyn Feature>) -> MyStruct {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    pub fn action(self) -> String {
⁠      let my_service = MyService::new(self.feature.clone());
⁠      println!("{}", my_service.action());
⁠
⁠      self.feature.action().to_owned()
⁠    }
⁠  }
⁠}

Como quiera que Rc implementa Clone, puede ser llamado sobre self.feature para obtener una copia del mismo y que sea consumida por otro objeto.

Un último caso que se puede encontrar es el del código asíncrono. En esta situación Rc no será de utilidad, pues no es seguro para subprocesos ni multi-threading.

⁠Los siguientes ejemplos harán uso de Tokio para el runtime asíncrono, así como de async_trait para poder crear traits con métodos también asíncronos.

Por ejemplo, si MyStruct implementase un trait MyStructTrait, el compilador advertirá de que MyStructTrait y Feature deberían implementar Send + Sync :

language-rust
⁠
mod my_struct {
⁠  use super::feature::Feature;
⁠  use async_trait::async_trait;
⁠  use std::rc::Rc;
⁠
⁠  pub struct MyStruct {
⁠    feature: Rc<dyn Feature>,
⁠  }
⁠
⁠  #[async_trait]
⁠  pub trait MyStructTrait: Send {
⁠    fn new(feature: Rc<dyn Feature>) -> Self;
⁠    async fn action(&self) -> Result<String, String>;
⁠  }
⁠
⁠  #[async_trait]
⁠  impl MyStructTrait for MyStruct {
⁠    fn new(feature: Rc<dyn Feature>) -> Self {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    async fn action(&self) -> Result<String, String> {
⁠      self.feature.action().await
⁠    }
⁠  }
⁠}

language-rust
⁠
error: future cannot be sent between threads safely
⁠  --> src/with_arc.rs:31:54
⁠   |
⁠31 |       async fn action(&self) -> Result<String, String> {
⁠   |  ______________________________________________________^
⁠32 | |       self.feature.action().await
⁠33 | |     }
⁠   | |_____^ future created by async block is not `Send`

Es posible decirle al compilador que extienda Feature y MyStructTrait con Send + Sync; pero encontraremos otro obstáculo: x cannot be sent between threads safely.

language-none
⁠
error[E0277]: `Rc<(dyn with_arc::feature::Feature + 'static)>` 
⁠  cannot be sent between threads safely
⁠  --> src/with_arc.rs:26:8
⁠   |
⁠26 |   impl MyStructTrait for MyStruct {
⁠   |        ^^^^^^^^^^^^^ `Rc<(dyn with_arc::feature::Feature + 
⁠                          'static)>
⁠       ` cannot be sent between threads safely

El puntero Rc es útil en código síncrono, pero no es seguro para subprocesos: para este caso Rust expone Arc, que, según la documentación: «... provides shared ownership of a value of type T, allocated in the heap. […] Unlike Rc<T>, Arc<T> uses atomic operations for its reference counting. This means that it is thread-safe.»

Usando Arc consumiremos algo más de memoria que con Rc, pero para este caso es una cantidad que fácilmente puede ser ignorada. Por otra parte tiene la ventaja de que implementa Clone, con lo que es posible realizar self.feature.clone() para pasarlo a Service.

language-rust
⁠
⁠mod my_struct {
⁠  use super::feature::Feature;
⁠  use async_trait::async_trait;
⁠  use std::sync::Arc;
⁠
⁠  pub struct MyStruct {
⁠    feature: Arc<dyn Feature>,
⁠  }
⁠
⁠  #[async_trait]
⁠  pub trait MyStructTrait: Send + Sync {
⁠    fn new(feature: Arc<dyn Feature>) -> Self;
⁠    async fn action(&self) -> Result<String, String>;
⁠  }
⁠
⁠  #[async_trait]
⁠  impl MyStructTrait for MyStruct {
⁠    fn new(feature: Arc<dyn Feature>) -> Self {
⁠      MyStruct { feature }
⁠    }
⁠
⁠    async fn action(&self) -> Result<String, String> {
⁠      self.feature.action().await
⁠    }
⁠  }
⁠}

Conclusión

La conveniencia de los genéricos sobre los trait objects dependerá del contexto. Los genéricos tendrán mejor performance por necesidad, puesto que su tamaño es conocido en tiempo de compilación; los trait objects, por otra parte, serán enviados al heap y usarán dispatch dinámico, lo cual tendrá un mayor consimo de memoria; pero la flexibilidad que ofrece quizás sea beneficiosa en comparación.

Para resumir, cada uno de los punteros: Box, Rc o Arc, nos ofrecerá diferentes acciones:

• Box: código sincrónico donde la instancia será consumida una sola vez.
• Rc: código sincrónico donde la instancia debe ser clonada para pasarla a distintas factorías.
• Arc: código asíncrono que requiere seguridad de subprocesos.

Con estas cuatro opciones —genéricos, Box, Rc y Arc— es posible obtener una inversión de dependencias correcta y aplicar los patrones que pueda requerir nuestro código.

El código completo de los cuatro ejemplos puede encontrarse en  git.antoniodiaz.me/antoniodcorrea/rust-dependency-inversion .

Algunas notas sobre conversión de tipos entre Rust y Postgres usando tokio-postgres, cliente asíncrono de PostgreSQL para Rust.

Hay dos posibilidades de mapeado entre tipos de Rust y tipos relacionados a la infraestructura que se esté usando, por ejemplo Postgres:

• Conversión de tipos de Postgres a Rust.
• Conversión de tipos de Rust a Postgres.

Esta librería expone algunos traits con implementaciones básicas que pueden ser usadas para convertir los tipos de nuetra aplicación entre tipos de PostgreSQL, y a la inversa. A modo de ejemplo, está FromSQL, que convertirán primitivos de Rust en tipos de Postgres: un bool de Rust será transformado en un bool de Postgres; i64 en bigint, &str o String en text, etc. Se debe tener cuidado en la conversión, y podemos encontrar algunos resultados indeseados si el usuario no tiene claro cómo los tipos están siendo convertidos; pero en general está bien documentado y es consistente con las expectativas.

El problema surje cuando se precisa realizar una conversión de tipos entre objetos o tipos más complejos, como un enum de Postgres y un enum de Rust. Esta funcionalidad se puede encontrar frecuentemente en librerías que ofrecen alguna variante de Object Relational Mapping. Afortunadamente, tokio_postgres no lo hace.

Es importante remarcar «afortunadamente»: los ORM suelen ser promocionados como una manera de acelerar y facilitar el desarrollo para tareas relativamente sencillas; pero incorporan al código serios problemas, razón por la que se les ha dado en llamar el Vietnam of Computer Science.

El debate sobre las posibilidades y conveniencia del Object Relational Mapping es largo y está lleno de sutilezas. Entre otros encontramos dos problemas principales:

• Fuerzan al desarrollador a acoplar las entidades y la infraestructura..
• Son incapaces de traducir consistentemente el espacio entre objetos y estructuras relacionales, a excepción de casos muy sencillos. La optimización proporcionada por SQL se pierde en cualquier caso no trivial, con duplicaciones de queries que pueden suponer un serio problema de eficiencia.

El hecho de que tokio-postgres carezca de funcionalidades ORM y requiera al usuario mapear manualmente entre tipos de Rust y Postgres no sólo no supone un inconveniente, sino que es un indicio de buenas prácticas.

Mapeando de SQL a Rust

Como se ha mencionado, tokio-postgres expone un trait FromSQL con implementaciones básicas para primitivos y algunos tipos espeficos. Con estas implementaciones el usuario no tiene que preocuparse de la conversión entre text y String, o entre bigint y i64.

El problema surge cuando se requiere realizar una conversión entre tipos complejos, como entre un myenum de Postgres y un MyEnum de Rust.

language-postgres
⁠
⁠create type myenum as enum('variant_a', 'variant_b');

language-rust
⁠
⁠pub enum MyEnum {
⁠  VariantA,
⁠  VariantB,
⁠}

Las conversiones de enums no están implementadas en tokio-postgres, ya que esta librería no ofrece ninguna funcionalidad de mapeado Object <-> Relational: aquí es donde es útil el trait FromSQL expuesto por esta librería, y que puede ser usado por el usuario para crear una implementación propia para el enum MyEnum de Rust.

El trait FromSQL expone cuatro métodos, de los cuales se pueden usar dos para crear la implementación requerida: from_sql, que se encargará de la conversión entre tipos, y accepts, que comprobará si la conversión debe ser realizada para un tipo determinado.

language-rust
⁠
pub trait FromSql<'a>: Sized {
⁠  fn from_sql(ty: &Type, raw: &'a [u8]) -> Result<Self, Box<dyn Error + Sync + Send>>;
⁠  […]
⁠  fn accepts(ty: &Type) -> bool;
⁠}

Se trata de una tarea sencilla: from_sql deberá producir las variantes correctas del enum, que se podrán obtener haciendo match contra el raw string binario; en accepts podemos comprobar que el enum que vamos a convertir tiene el nombre correcto.

language-rust
⁠
impl FromSql<'_> for MyEnum {
⁠  fn from_sql(_sql_type: &Type, value: &[u8]) -> Result<Self, Box<dyn Error + Sync + Send>> {
⁠    match value {
⁠      b"variant_a" => Ok(MyEnum::VariantA),
⁠      b"variant_b" => Ok(MyEnum::VariantB),
⁠      _ => Ok(MyEnum::VariantA),
⁠    }
⁠  }
⁠
⁠  fn accepts(sql_type: FromSqlType) -> bool {
⁠    sql_type.name() == "myenum"
⁠  }
⁠}

Como se trata de una funcionalidad directamente relacionada con Postgres, puede localizarse en el repositorio o módulo acoplado a la base de datos, manteniéndolo fuera de la capa de dominio. De este modo se evita crear una dependencia de dominio hacia infraestructura, siendo esta última quien referencia al dominio —cuando menciona MyEnum por ejemplo—, y no a la inversa.

Esta implementacion describe a la librería tokio-postgres cómo realizar la conversión de tipos entre SQL y Rust para este tipo específico, de modo que siempre que una query devuelva un tipo myenum de Postgres aparecerá en la aplicación como MyEnum.

Mapeando de Rust a SQL

Para realizar la conversión inversa, de Rust MyEnum a Postgres myenum, se puede implementar el trait ToSql usando los métodos to_sql y accepts:

language-rust
⁠
pub trait ToSql: fmt::Debug {
⁠    fn to_sql(&self, ty: &Type, out: &mut BytesMut) -> Result<IsNull, Box<dyn Error + Sync + Send>>
⁠    where
⁠        Self: Sized;
⁠    fn accepts(ty: &Type) -> bool
⁠    where
⁠        Self: Sized;
⁠    fn to_sql_checked(
⁠        &self,
⁠        ty: &Type,
⁠        out: &mut BytesMut,
⁠    ) -> Result<IsNull, Box<dyn Error + Sync + Send>>;
⁠}

Además hay que implementar to_sql_checked, pero el macro types::to_sql_checked! puede generar esta implementacion automaticamente.

Cuando implementamos to_sql las variantes de MyEnum tienen que ser transformadas a &str antes. Para ello hay que primero implementar Display para MyEnum, de modo que podamos posteriormente implementar ToSQL.

language-rust
⁠
use std::fmt::{Display, Formatter, Result };
⁠
⁠impl Display for MyEnum {
⁠  fn fmt(&self, f: &mut Formatter) -> Result {
⁠    match self {
⁠      MyEnum::VariantA => write!(f, "variant_a"),
⁠      MyEnum::VariantB => write!(f, "variant_b"),
    }
⁠  }
⁠}

Una vez implementado Display para MyEnum es posible implementarToSql , igualmente para MyEnum:

language-rust
⁠
use tokio_postgres::{
⁠  types::{to_sql_checked, ToSql, IsNull, Type},
⁠};
⁠use bytes::BytesMut;
⁠use std::{error::Error, result::Result};
⁠
⁠impl ToSql for Role {
⁠  fn to_sql(&self, ty: &Type, out: &mut BytesMut) -> Result<IsNull, Box<dyn Error + Sync + Send>>; {
⁠    format!("{}", self).to_sql(ty, out)
⁠  }
⁠
⁠  fn accepts(sql_type: &Type) -> bool {
⁠    sql_type.name() == "myenum"
⁠  }
⁠
⁠  to_sql_checked!();
⁠}

De esta manera siempre que Postgres reciba un enum de Rust MyEnum, éste será convertido en un enum de Postgresmyenum.

Conclusión

Cabe mencionar otros casos donde será necesario realizar conversiones entre tipos, como sucede con el tipo Row, que podrá ser usado con el trait From de Rust para convertir entre filas de Postgres y objetos de Rust de la aplicación.

Por ejemplo, para un determinado struct Article, la implementación de From para este struct tendrá este aspecto:

language-rust
⁠
// Domain
⁠pub struct Article {
⁠  pub id: String,
⁠  pub title: String,
⁠  pub created_at: DateTime,
⁠}
⁠
⁠// Repository
⁠impl From<Row> for Article {
⁠  fn from(row: Row) -> Self {
⁠    Self {
⁠      id: row.get("id"),
⁠      title: row.get("title"),
⁠      created_at: row.get("created_at"),
⁠    }
⁠  }
⁠}

⁠let result = client.query("select * from article").await?;
⁠let articles: Vec<Article> = result.into_iter()
⁠    .map(Article::from)
    ⁠.collect();

Como se puede apreciar en general esta librería es bastante sencilla de usar siempre que se consulten los traits expuestos, ofreciendo unas funcionalidades bien delimitadas y facilitando al usuario extenderlas implementando estos traits.