Erlang y Haskell con Kiko Fernández

Pues buenas a otra sesión más de codeadores. Hoy tenemos una sesión que yo creo que es casi como una especie de redención, porque el capítulo más corto que tenemos a día de hoy es hablando de Erlang. Así que he aprovechado que Kiko Fernández Reyes se había puesto en contacto conmigo para hablar un poco más sobre Erlang, y dada que trabaja en el grupo de Erlang que está dentro de Ericsson, yo creo que es una de las personas que sabe un poco qué se está cociendo dentro de Erlang y cómo va el desarrollo. Pero vamos, voy a darte pie en principio para que te puedas presentar, nos digas quién eres, un poco de tu historia. Y sobre todo, la primera pregunta que me gusta a mí siempre hacer es cómo entraste en este mundo de la informática. O sea, ¿cuál fue ese pequeño detalle o ese primer acercamiento que te hizo pensar de Me quiero dedicar a esto.

Hola, Manuel, gracias por la introducción. Pues sí, soy Kiko Fernández, nací en Málaga, vale, pero yo me crié realmente en la zona de Almuñécar, la zona de Granada. El cómo empecé programando, pues yo creo que sería cerca de los 14, entre los 14 y los 17. Teníamos un un ordenador así muy simplón. Y no sé por qué vino un amigo un día a casa y dijo que él sabía programar un poco en algún BASIC, creo que era. Y empezó a enseñarnos un poco cómo hacer eso. Y a partir de ahí yo tenía interés, no sé por qué, en hacer algún tipo de conversación como si el ordenador te estuviera respondiendo. Pero claro, mi conocimiento era súper limitado. Entonces yo intentaba hacer un matching, como quien dice, de ciertas palabras A lo mejor eran más bien como insultos o cosas de esas para hacer algo gracioso y que te respondiera y te insultara de vuelta, vale, o una cosa así. Y eso fue un poco como empecé al principio a tocarlo. Pero vaya, lo toqué un poco, lo vi, me interesó, y luego un poco se quedó ahí. Ya lo siguiente sería el paso por la universidad. En la Universidad de Málaga, pues sí, pues Estudié, como quien dice, la carrera de Ingeniería Informática. Había en ese momento la técnica y la superior. Yo hice la superior y claro, el primer año fue darte de matemáticas en la cara, básicamente, porque aquello de programación tenía poco. Me parece que vimos un poco de C, C++ y no fue hasta el segundo año, o el segundo o el tercer año, que vimos ya un poquito más programación lógica y declarativa, que era con Prolog y Haskell. Y en aquel momento yo recuerdo Haskell no me gustó nada, yo no entendía absolutamente nada, pero Prolog para mí aquello fue, aquello fue lo mejor, sinceramente. A mí me encantaba Prolog, e incluso luego cuando hice un Erasmus me puse a usar Prolog para programar cosas que hacía falta con un tipo de lógica que hice en la universidad de Luxemburgo. Y ya pues por ahí pues eso, pues te vas poco a poco metiendo, como quien dice, y demás. Y ya de ahí pues sí, en cuanto que empieza el programa y empiezas a ver todo lo que es este mundo, ya te engancha. Ahí ya sí empecé ya a darle más. Pero Erland fue mucho más tarde, básicamente. Erland fue ya cuando estuve de verdad trabajando.

Entonces tú empezaste en Málaga, tus primeros trabajos serían por la zona. ¿En qué lenguaje empezaste profesionalmente trabajando localmente allí en Málaga? Porque mi recuerdo de España es que la mayoría de lenguaje y programación se reducen a C, PHP y poco más. ¿Cuáles fueron tus primeros lenguajes?

Sí, pues mira, realmente experiencia laboral en España remunerada no tengo ninguna. Todo es desde Suecia. Pero cuando empecé en Málaga sí era obligatorio hacer, ¿cómo se dice?, un internship. Y eso lo hice con una empresa que había en Málaga y eran cosas de Java web, básicamente Java Enterprise Edition creo que es. Y hice ahí algo, 3 meses y eso, pero vaya, en 2010 es cuando acabé yo la carrera y ahí mi mujer se quería seguir a estudiar un máster en en Suecia. Y yo que había acabado de acabar y era, pues mira, no tengo nada mejor que hacer, ¿por qué no tiramos para Suecia los dos y ya está? Entonces la verdad que ahí no tuve mucho. Pero vaya, si sigo tu pregunta simplemente enfocada en Suecia, ahí trabajé en una startup al principio pequeña y luego me contrató el grupo de Trifork. Entonces yo estuve en las oficinas de Erland Solutions porque Trifork es la que es propietaria de Erlang Solutions. Y ahí hicimos todo menos Erlang, básicamente, para no entrar en conflicto. Entonces nos tocaba hacer Ruby, Python, y tenían un producto financiero que hicieron en Clojure. Y ahí es cuando de verdad sí utilicé la programación funcional aplicada a un producto de verdad que se estaba vendiendo. Así que Y ya de ahí, como quien dice, desde que toqué Clojure ya han sido 15 años, como quien dice, de programación funcional.

Entonces, vamos, en la carrera caíste enamorado de Prolog y en el mundo laboral terminaste con Clojure, que es casi como otro dialecto de Lisp.

Exacto, es otro dialecto de Lisp, simplemente que funciona en la máquina virtual de de Java, pero sí. Y yo diría que, bueno, después eso fue como que hice los primeros pasos aquí en Suecia en industria. Después de eso eché un doctorado en la Universidad de Uppsala y entonces ahí me tocó hacer pues más programación funcional, pero ya con un lenguaje pues de tipos, porque se iba a hacer investigación en cosas de diferentes tipos de lógica aplicado a programas de programación, pues me tocaba Haskell básicamente. Habían empezado a hacer un proyecto, la idea era como quien dice hacer un proyecto usando actores o procesos como Erlang, pero con tipos. Y en vez de coger Erlang y tratar de tiparlo como quien dice bien o lo que sea, pues vamos a crear un nuevo lenguaje de programación que nadie conoce, ¿no? Y vamos a experimentar. Y bueno, pues el compilador y eso estaba todo escrito en Haskell. Entonces me especialicé bastante en Haskell. Al acabar el doctorado eché a Klarna, que es un banco, pero también te ofrece lo de pagar luego, como quien dice, buy now, pay later. Y allí les hacía falta pues gente que supiera Haskell y Erlang. Y yo venía con la experiencia de Haskell, pero no de Erlang. Pero dijeron, ah, pero si sabes Haskell, Erlang es más sencillo. Y llevaban razón. Lo que pasa es que les hacía falta tanta gente que supiera Haskell, que ese era el gran problema, porque es más complicado debido al sistema de tipos y demás, que en realidad no me usaron tanto, tanto para Erlang. Me usaban para todo lo que tenía que ver con Haskell. Seguí especializándome un poco en Haskell y yo me sentí un poquillo mal porque era como, ya, pero tengo que saber Erlang también, no puede ser que solo contribuya, hago cosas en Haskell. Entonces vi una librería que validaba JSON, se llama Jessie, empezó me parece en, o era mantenida por Claro, empezó en Claro, no recuerdo, pero vaya, yo quise contribuir con el siguiente la siguiente versión de la especificación. Y digo, pues mira, pues un día que demos un hackathon o algo, voy a ver si llego, como quien dice, a poder ayudar un poco y poner esas cosas nuevas. Y casi casi que lo conseguí. Y luego le pedí al manager simplemente si podía tener un par de días más para finalizarlo, y me dijo que sí. Y ahí entonces fueron los primeros pasos con Erlang, realmente a base de un hackathon que salió de Klarna. Si no, no hubiera estado ahí.

Has dicho que en la parte del doctorado, incluso tus primeros pasitos en el cloud fueron con Haskell, pero también que era el lenguaje que más odiabas en la universidad. ¿En qué momento cambiaste el chip y dijiste, bueno, vale, Haskell está bien?

Ya, muy buena pregunta. Pues yo creo que sería más bien durante el doctorado, porque cuando yo estaba en la universidad Haskell era como que no lo entendía, y no había quien entendiera el Monad, creo. Y entonces, no sé, fue simplemente la universidad, como tuve que hacer, pues no sé, fueron 6 años o 7 del doctorado y era todo en Haskell, así que tocaba aprenderlo, básicamente, no había mucho más. Y mi supervisor en ese momento era alguien extremadamente matemático. Y entonces empecé a meterme en teoría de categorías, creo que se llamaría en español, que es una matemática pero extremadamente abstracta. Y por ahí, si te empiezas a meter un poco saltándote las demostraciones matemáticas, empiezas a entender por qué Haskell es como es. Y la verdad que tiene sentido. Y en cuanto que hace un clic, dices, ah, Hostia, ya entiendo por qué esto funciona de esta manera y demás. Y una vez que lo entiendes es todo súper sencillo, pero llegar hasta entenderlo cuesta, vale. Pero ya te digo, una vez que llegas ya es, ah, ya entendió, como quien dice, que uno puede meter una mónada dentro de otra y cómo extraerla. Y en fin, todas esas cosas ya no es tan complicado, pero cuesta llegar. Y bueno, ya cuando llegas dices, ah, bueno, pues me ayuda un montón. Porque me detecta un montón de cosas de manera estática. Algunas cosas son un poco más, ¿cómo diría? Verbosas, en cierta manera, de escribir, simplemente porque tienes que poner unos tipos un poco raros, pero funciona súper bien, la verdad. Entonces, bueno, si coge errores antes de que sea en runtime, tampoco está mal.

Has dicho también que Klarna te contrató porque sabías Haskell y estaban dispuestos a enseñarte Erlang. Yo tengo constancia de que Klarna es uno de los empleadores que más personal tiene programando en Erlang. ¿Cómo encaja en su sistema tener Erlang y tener Haskell?

Muy buena pregunta. En este caso había diferentes equipos, vale, y te estoy hablando de 2020-2021, creo. En este caso, mi equipo era el que se encargaba de toda todo lo que va por tarjeta de crédito. Y yo creo que eso es prácticamente casi todo el negocio. Nosotros éramos el principal punto de entrada, básicamente. Y de ahí entonces lo que teníamos que hacer era, pues, cada vez que quieres pagar o algo, esa parte estaba en Erlang. Lo programamos para poder lanzar algún request a Mastercard o a Visa o a quien hiciera falta, como quien dice, y esperar a que viniera una respuesta en algún momento y demás. Entonces todo es asíncrono, sinceramente. Y para todo lo que es I/O, entonces entrada o salida de datos o cosas de redes, Erlang es que es una maravilla, sinceramente. Y si hay cosas que no te envían después de cierto tiempo, no sé qué, pues puedes hacer un crash y no pasa nada, el sistema se recupera y sin ningún problema. Ahora, eso era la parte de Erlang. La de Haskell, había un grupo, como quien dice, de no sé si éramos pues 80 a 100 personas que estaban haciendo proyectos en Haskell, pero lo que nos tocó a nosotros en concreto no tenía apenas casi nada de redes o comunicación o algo. Uno de ellos era recoger un fichero donde vienen todas las transacciones que se han hecho al final del día y tenías que parsearlas en JSON y después construirte, como quien dice, pues algún tipo de tu propia base de datos para hacer más queries o cualquier historia de estas, vale. Y para eso Haskell, como quien dice, funcionaba muy bien sinceramente. Pero en Haskell nunca llegamos a hacer mucho la parte de cosas de forma paralela o cosas así. La verdad era más cosas single-threaded y más de procesamiento que hacía falta hacer, básicamente. Pero vaya, eso era nuestro equipo. Otros equipos creo que sí tenían un poquito más de comunicación con más redes y demás, pero en nuestro caso era algo bastante sencillo. Y lo único es que ahí podías ver un poco también la diferencia entre Haskell y Erlang. Teníamos un sistema donde podíamos monitorizar todo lo que pasaba en Erlang, vale. Y la memoria que consumía es que era increíble, es que no se movía, es que era estable. 3 gigas creo que era o algo así. Y de ahí a aquello, da igual que le estuvieran metiendo toda la caña que tú quisieras, que es que no se movía. Aquello era perfecto. Sin embargo, en Haskell, un sistema como quien dice que era simplemente consumir ficheros JSON en plan gordillo, no sé si era 1 giga o 2 gigas, pues debido a una cosa que se llama space leaks, que es un leak de memoria que puede pasar de vez en cuando en Haskell, lo que pasaba es que Pues yo qué sé, pues a lo mejor leer, como quien dice, eso, un giga o dos de datos, pues te consumía también un giga de memoria RAM o más. Y tú decías, ya, pero es que cuando venga a lo mejor el Black Friday o algo, eso no va a ser 2 gigas, eso a lo mejor son 10. Y yo no quiero que me consuma 10 gigas de memoria Haskell, ¿no? Y en este caso todo tiene que ver porque Erlang es un lenguaje donde es estricto, como quien dice. Entonces, si tú pasas un argumento a una función, Eso se evalúa antes, mientras que en Haskell lo encapsulas, como quien dice, y dices ya lo evaluaré cuando me haga realmente falta. Y así pues puede que vayas acumulando bastante memoria, porque si no lo llamas hasta muy tarde, pues ahí queda básicamente la computación sin hacerse.

Parece que le falta todavía un poco de optimización en ese sentido, aunque creo O sea, porque muchas veces hemos hablado en conferencias en Erlang sobre eso, lo que tú decías de la entrada y salida de datos es maravillosa en Erlang, el control de alta carga, pero sin embargo cuando decían en inglés lo de crunching numbers, tomar y hacer muchas ecuaciones matemáticas sobre los números, ahí ya, igual que hace Klarna el uso de Haskell, Otros pues tomaban otros lenguajes, otros sistemas para tomar la potencia de donde allí no llegaba Erlang. Recuerdo que había muchos en San Francisco cuando estuve allí en las conferencias. Bruce Tate defendía el uso de Julia, por ejemplo, para hacer ese tipo de cálculos. Y otros pues tenían R y tenían otros lenguajes que hacían similar. No sabía exactamente para qué se utilizaba Haskell en Klarna, pero ya me queda claro que ese era el uso seguramente de para trabajar con esos datos numéricos y hacer todas las cuentas donde se supone que Erlang tiene sus flaquezas. Entonces, cuando estás en Klarna, empiezas a saber ya sobre Erlang, aprender sobre Erlang. ¿Cuál es el siguiente paso en tu carrera? Tienes ahí Haskell, tienes Erlang, decides tirar por Erlang.

En este caso fue un poco curioso. En Klarna ahora ya no sé cómo lo están haciendo, pero yo me fui simplemente porque dijeron vamos a reemplazarlo todo con Java, vale. Y yo dije ya, yo no voy a, o por lo menos la parte de Haskell se va a reemplazar con Java, y la parte de Erlang sé que poco a poco han ido separándolo un poquito para que pueda ser más, no un un código monolítico, sino algo más separado que se puede mantener en diferentes equipos. Y eso me parecía bien. Pero cuando me dijeron que me iban a quitar Haskell y me iban a poner a hacer Java, yo pensé, ya no. Yo lo siento mucho por Java, no tengo nada en contra, pero yo prefiero seguir con programación funcional antes que meterme a eso. Y entonces me puse a buscar empleo y vi que estaba una posición aquí en Ericsson para entrar en el Erlang OTP equipo. Y pensé, bueno, yo voy a echar como quien dice a ver qué sale. Les voy a decir claramente que mi experiencia en Erlang es un poco no común, o que no soy experto básicamente, aunque he trabajado en Klarna. Y a ver qué pasa. Y en ese caso, Kenneth, que ahora ya está retirado, me hizo la entrevista y demás. Hablamos, vio que tenía un doctorado, vio que a lo mejor pues igual podía contribuir a cosas, me imagino, en en Dialyzer, que es una herramienta que Erlang no tiene tipos, pero trata como de tenerlos, y si tú los añades, Dialyzer es una herramienta que puede detectar algunos errores de tipado. Y bueno, pues me imagino que pensando en eso o algo, me hicieron un par de entrevistas y al final me cogieron. Yo, para mí, lo chulo fue que no hubo que hacer absolutamente nada de entrevista de código típica que tardas yo qué sé, te dan unas semanas para hacer algo. No, no, fue entrevista, consultar con gente que había trabajado, me parece, anteriormente, cómo había ido y demás. Y todo bien, la verdad. Así que el siguiente paso fue Ericsson y aquí sigo después ya de 3 o 4 años, creo. O sea que bien.

Entonces, tu principal desempeño dentro de Ericsson y dentro del equipo de OTP ¿Se basa en trabajar con Dialyzer?

Es una buena pregunta. Al principio, cuando iba a entrar e hice todas las entrevistas y eso, me dijeron que yo entraba en el equipo de— hay dos equipos, compiladores y protocolos, o máquina virtual y protocolos. Y yo dije, yo quiero el de máquina virtual, yo de protocolos no tengo ni idea, vale. Y me dijeron, no, tú vas a entrar en máquina virtual.

Súper.

Entro a trabajar en Ericsson y el primer día me dicen, no, es que ha habido alguno que se ha ido y el equipo de protocolos está un poquito cojo, así que te va a tocar hacer protocolos. Y claro, pues fue difícil empezar porque además la manera en la que empecé haciendo más Erlang fue Kenneth diciéndome, tenemos aquí un race condition que no sabemos dónde pasa. En la aplicación FTP. Búscate cómo solucionarlo. Y claro, yo ya le había dicho que no tenía mucha experiencia haciendo debugging de Erlang o algo. Entonces, busca dónde pasa tú el race condition y ponte a mirar la especificación de FTP y demás, ¿no? No fue la mejor introducción, diría yo. Pero bueno, de ahí como que inicié fue, definitivamente cogí la práctica de hacer cosas con Erlang. Y luego en algún momento ya les dije que sí, que yo preferiría. Y yo pensé que yo podía aportar más al equipo de la máquina virtual que al equipo de protocolos, porque no sé prácticamente nada de protocolos. Y entonces ya hice por fin un cambio, pero a pesar de que he hecho el cambio, todavía no estoy haciendo, como quien dice, mucho de dialyzer o de la máquina virtual. Esto quizás más bien un poco culpa mía por cosa de los diferentes roles que he ido cogiendo. Prácticamente desde que entré en Ericsson he sido el chair del Erlang Workshop. Este es el tercer año consecutivo y ya no hay más porque ya me tienen que echar, básicamente se va rotando. Y claro, entonces pues me toca hacer también eso como parte del trabajo. Y luego también yo actúo mucho en el tema del Erlang Ecosystem Foundation. Y eso es porque tiene que haber una coordinación con ellos para ver que lo que quiere la fundación está medio alineado también con cosas que viene bien para Erexon. Y me imagino que lo mismo para Elixir y Glimpse, que son los otros lenguajes que funcionan en la máquina virtual de Erlang. Porque no puede ser que la fundación a lo mejor vaya completamente por un lado donde no es en el beneficio de todo el mundo. Entonces, debido a eso, hago un poco de trabajo, como quien dice, en el equipo de máquinas virtuales, la máquina virtual de Erlang, pero no tanto como me gustaría, básicamente.

Hablando desde el desconocimiento de cómo funciona la organización del equipo, en la parte de protocolos, y teniendo en cuenta de que hay librerías como Cowboy y otras librerías que implementan los protocolos desde cero basándose en TCP y a partir de ahí, ¿No se ha pensado en algún momento en desechar esos tipos de protocolos y quizás lanzarlos en el repositorio, pero como proyectos aparte, como dependencias, en lugar de dejarlos dentro del núcleo?

Sí, sí que se ha pensado. El único motivo por el que hay ciertas librerías que todavía permanecen bajo el repositorio de Erlang UTP es porque Ericsson la sigue utilizando. Entonces tenemos que mantenerlas. Hay algunas que creo que llevan a lo mejor años sin tocarse porque funcionan y ya creo que no hay mucha más evolución básicamente en el protocolo, pero tienen que estar mantenidas. Si de repente alguien tiene un problema en el código que Ericsson crea, pues hay que darle respuesta. Entonces eso hace que tengamos un poquito ahí de carga con cosas que nos gustaría poder desechar, pero que tienes que todavía mantener por si acaso, básicamente. A ver si conseguimos, como quien dice, que haya otras librerías, o que los equipos de Ericsson que todavía utilizan algunas librerías más antiguas pudieran ir quitándolo. Pero eso es complicado porque significa que si funciona no lo toques, ¿no? Así que ya.

¿Y cómo se vive la presión de que haya otros lenguajes aparte de Erlang? Porque eso es otra cosa que quizás también se podría separar de la máquina virtual y dejar aparte, que pudieses decidir pues no quiero instalar el intérprete de Erlang sino solo el de Elixir o solo el de Grimm. Se podría, bueno, probablemente no, pero Si se pudiese, la presión que hay de otros lenguajes para hacer el trabajo y demás, ¿tú lo ves como algo positivo o negativo?

Lo que has dicho de tratar de separarlo, la verdad que no tengo suficiente conocimiento para ver si eso se pudiera. Me parece complicado, pero hablo desde el desconocimiento. Pero el tema de si Elixir y Glimpse nos mete un poco de presión a nosotros. Bueno, yo no lo veo como presión, pero sí como inspiración. Yo creo que hay cosas que Elixir, especialmente Elixir, ha hecho que nosotros hemos pensado, ah, pues mira, pues es verdad que esto podría ayudar bastante a programar Erlang un poquito más sencillo. Entonces se discute, como quien dice, si merece la pena tratar de añadir algo parecido. Y si creemos que sí, oye, pues estupendo. Y si vemos que no, pues no. Una de las cosas, por ejemplo, en el futuro, que no sé si va a pasar, pero que a mí me gusta, son protocolos. Yo los conocía por Clojure y me parece que Elixir tiene algo parecido. Estaría súper bien si pudiéramos añadirlo en Erlang. Y algunas veces hemos dicho, Pues oye, igual estaría bien. Así hay un poco más de sentimiento dinámico, más, pero claro, hacer todo eso es también más mantenimiento de cosas que a lo mejor no te hacen falta estrictamente. Entonces hay que sopesar un poco muy bien, ¿añadimos más cosas o preferimos quedarnos como estamos a pesar de que otros lenguajes están añadiendo cosas que a todo el mundo le gusta y esto es, pero es cuestión de mantenimiento. Y yo siempre digo lo mismo, en Ericsson el equipo que mantiene OTP, el equipo que mantiene la máquina virtual y todo el lenguaje, creo que somos 15 personas. Pero es que si tú te vas, como quien dice, yo conozco a gente de Oracle que trabaja en la máquina virtual, 15 a 20 personas es el equipo que trabaja en la parte de colección de basura, el garbage collection. Entonces, hombre, es que no es el mismo tamaño, como quien dice, sinceramente, vale. Entonces se intenta decidir lo que creemos que merece la pena. Y entonces sí, pero como te digo, yo lo veo como inspiración, la verdad. Creo que nos ayuda a lo mejor a atrevernos algunas veces a hacer cosas.

Otra cosa que me di cuenta de que cuando la comunidad empezó a crecer gracias a otros lenguajes, principalmente Elixir, pero también Glimpse, la velocidad de lanzamiento de nuevas versiones se incrementó. Incluso creo que ahora mismo, coincidiendo con cada CodePin anual, se lanza la siguiente versión de OTP. Creo que este año toca la 28, ¿no?

Sí, justo 28.

¿Qué trae la versión 28?

Pues la versión 28 trae una cosa nueva que se llama, en cuanto a Dialyzer, el sistema estático de tipos, que se llama Nominal Types. Y esto es porque en Erlang teníamos los— en Erlang básicamente todos los tipos son un alias. Es decir, si tú pones que el tipo Foo es un integer, realmente es un integer. No comparas a nivel de yo quiero comparar Foo con Foo. No, comparas Foo y puede ser luego con cualquier otro integer. Entonces puedes estar comparando, como quien dice, manzanas con naranjas, ¿vale? Y lo que hace el sistema este nuevo que se llama Nominal Types es decir, no, si yo te doy algo que es de tipo manzana y te paso ahora algo que es una naranja, pues me lo tienes que rechazar. Aunque los dos internalmente sean a lo mejor un integer o un número real o un número natural o algo, el tipo es distinto. Por lo tanto, no me lo aceptes, vale. Y creemos que eso puede ayudar bastante pues en cosas, por ejemplo, pues donde hace falta. Por ejemplo, en SSL hay ciertos tipos que si pasas tienen la misma representación internamente, a lo mejor es un integer, pero es que tú no quieres mezclar un tipo de integers con otro tipo porque representan cosas completamente distintas, vale. Entonces eso sería algo pues que ahí te puede ayudar. Luego tiene después otras cosas como ahora puedes, como quien dice, unir binarios, sería combinarlos y unirlos, por ejemplo, con un carácter separador, vale. Para que es una cosa muy típica que uno quiere hacer generalmente, tienes una lista de cosas y dices las quiero unir y poner simplemente un carácter separador en cada uno, no. Bueno, pues eso también es fácil. Y vienen como siempre muchas cosillas en el runtime system. Siempre se trata de que nunca haya un retroceso, como quien dice, en el performance. Entonces en este caso creo que hay ciertas cosas que siempre se han intentado mejorar y se han conseguido, pero lo mejor sería entonces pues leer, como quien dice, las notas al final cuando lo publiquemos, que será en en un par de días, creo, en una semana creo que sale ya la nueva versión.

Así que aprovechando que estás trabajando en la parte de tipos del dialyzer principalmente, recuerdo haber asistido a unas cuantas Elixir Conf en el que se iba avanzando sobre los tipos que se están implementando en Elixir, conjunto de tipos teóricos creo que, creo que nunca me acuerdo cómo es en inglés. Y recuerdo que se hizo una investigación a través de una universidad con un alumno que estaba haciendo su investigación con la dirección de un profesor, y Josep Alí estaba ayudándoles con la parte de la investigación y después con la parte de la implementación. Dicen que en esta versión, la Elixir 18, ya tienen gran parte de los tipos implementados, y de hecho estaban haciendo demostraciones de cómo se va quejando el compilador cuando se utiliza utilizan tipos que no son compatibles aunque sean del mismo estilo, como lo que has comentado con Dialyzer. Tengo también recuerdo de que WhatsApp estuvo haciendo algo similar, creo que se llamaba Equalizer la implementación que hicieron para probar los tipos a Erlang. ¿Hay alguna iniciativa dentro de Erlang de retomar este tema? Porque claro, hay trabajos de WhatsApp, hay trabajos paralelos con Elixir, ¿Se ha contagiado eso un poco dentro de Erlang o va a seguir todavía igual?

Yo diría que sí se contagia un poco, dado que tengo como quien dice un poco el background de haber hecho el doctorado, esto, lo otro. Entonces siempre he tratado de ver si eso lo podía meter un poco. Yo notaba que desde que Ericsson dejó, bueno, no Ericsson, Erlang OTP dejó la colaboración con el equipo de Kosti Sagonas en Uppsala. No ha habido mucha más colaboración que yo sepa con ningún otro equipo, y yo quería ver si podíamos volver a traer a la gente, los académicos, los researchers y demás, para que sigan investigando. Porque de ahí es de donde nosotros podemos ver si algo se ha aplicado y parece que funciona, podemos tirar un poco más del hilo a ver si funciona, ¿no? Y basándonos en eso Es curioso que lo digas porque vamos a ver si podemos, como quien dice, echar un proposal para un proyecto europeo junto con Elixir, Giuseppe Castagna, que es el researcher de la Universidad de París, si no me equivoco, y también gente de Alemania, para ver si podemos meter lo que tú has dicho, que en inglés se llama set theoretic types, en Erlang y en Elixir. Y si se pudiera, idealmente sería un código, como quien dice, común, donde cada uno tiene abstract syntax tree de cada lenguaje a su manera, pero luego el algoritmo, como quien dice, que hace el sistema de tipos, que sea común para que sea mantenido un poco por las dos comunidades. Y yo creo que eso a nosotros nos ayudaría, porque por lo que Hemos visto y creemos, si utilizamos este nuevo sistema de tipos, muchas de las cosas que Dialyzer ahora mismo no reporta las podría reportar. Y creemos que no va a llevar, no vamos a romper la retrocompatibilidad. Por lo tanto, vemos bastante beneficio. Pero claro, la cosa es, no nos podemos meter en un proyecto así de gordo nosotros solos porque no somos los expertos en este en esta teoría. Entonces necesitamos aliarnos, como quien dice, pues con algún researcher que sepa. Y dado que Josep Valen ya ha probado y ha visto que funciona bastante bien en Elixir, a nosotros nos convence que igual, oye, pues es algo donde deberíamos de investigar también y tratar de crear algo que funcione y que podamos mantener más, pues un poco como una comunidad. En Dialyzer ahora mismo hay cosas que es muy difícil de que podamos solucionarlas. Hay errores sobre todo con algo que se llama opaques. Eso es mejor no— el que quiera que abra un ticket, va a ser difícil que podamos solucionarlo. Entonces sabemos que estamos llegando al límite con la teoría que tenía Dialyzer, pero con la nueva teoría parece que puede englobar Dialyzer y más. Por lo tanto, es algo bueno. Y ahí queremos ver si conseguimos sacar este proyecto europeo y, por lo tanto, seguir expandiendo un poco y aumentando las capacidades de Dialyzer. En tema después de Equalizer, nosotros hablamos con WhatsApp y demás, pero todavía no estamos seguros de— Equalizer tiene algunos assumptions que nosotros no sé si podemos tomar, a no ser que cojas Equalizer. Entonces nosotros no podemos cambiar la semántica de los tipos que tiene ahora mismo Erlang a que sea exactamente lo que Equalizer hace, porque no cuadra al 100%. Entonces ahí lo vamos observando, hablamos con ellos, pero todavía no nos atrevemos mucho a tirar por ahí, la verdad.

Y hablando de Equalizer y Dialyzer, creo que solo nos falta la ecuación de Gradualizer. Que creo que era una iniciativa. De hecho, alguien de Erlang Solutions, creo que fue Radek, que no lo creo, pero está muy metido en el tema de Gradualizer. Y es así, corrígeme si me equivoco, porque esto es un terreno que he explorado muy poco. Es el análisis de tipos de forma gradual.

Sí, exacto. Este otro sistema de tipos, Gradualizer, utilizar lo que se llama gradual typing. Y en ese caso lo que haces es, cuando no sabes el tipo que esperas o es un tipo muy complejo, dices esto es dinámico. Quiere decir como averígualo, como quien dice. Y si no sabes, pues esa parte la vas a ignorar, no vas a poder corroborar que el tipo que esperas es justo lo que tú quieres, vale. Y eso es más o menos un poco también, ahí la verdad que es un poco curioso porque Si no recuerdo mal, Gradualizer salió de Facebook y Equalizer ha salido de WhatsApp. Pero Equalizer de WhatsApp, de verdad, sí, sí lo utilizan mucho internamente y lo mantienen y van haciendo nuevas releases y demás. Pero Gradualizer, la verdad que no, no lo seguimos tanto. Me parece que se ha quedado un poquito más retrasado con respecto al que tiene WhatsApp. Y es gracioso porque los dos vienen básicamente de Meta, pero de alguna manera, no sé, habrá diferentes gustos para la semántica de tipos que aplique.

Es posible que encontrasen algún callejón sin salida, que llegas a un punto en el que no era lo que esperaban o no se puede seguir trabajando en esa dirección.

Pues sí. Y ahora ya encajándolo un poco, ahora que has mencionado el sistema de tipos graduales, en la propuesta que vamos a hacer para el proyecto europeo vamos a intentar meter también el tema de pues gradual typing a set theoretic types. Por lo tanto, ahí nosotros también intentamos meter eso porque en Erlang hay cosas que a lo mejor es bastante difícil de que puedas saber el tipo que le va a corresponder. Entonces ahí tienes como una pequeña cosa para decir, oye, no lo sé sinceramente. Esta parte la ignoras un poco y continúas con el resto, que sí sé.

Y aparte de la dialyzer y la parte de protocolo, dentro de Erlang se ha estado priorizando, creo que fue desde la versión OTP 21, el JIT de Just-in-Time para la compilación, que tuviese un poco más de rendimiento. Creo que ha habido un enfoque dentro del equipo de OTP en tener cada vez más rendimiento, porque era algo que se le achacaba desde hacía mucho tiempo. ¿Siguen todavía enfocándose en rendir mejor?

Siempre se intenta y siempre se trata de hacer con cada nueva versión algún tipo de optimización que no estaba. Lo que pasa que algunas veces es complicado o se hace a diferentes niveles. No todo se puede hacer a lo mejor en la parte del JIT. Algunas pues creas una nueva instrucción a lo mejor para la máquina virtual de Erlang y eso hace pues que te saltas un par de accesos o lo que sea. Y son micro optimizaciones. Si hay alguna optimización más grande que se pueda hacer, eso sería en la lista de comprensión. Me imagino que sería en español el list comprehension. Ahí es donde quizás se puede hacer algo más porque la semántica no te dice que tienes que ser capaz de observar cada paso que sucede. Porque esa es una de las cosas que mucha gente no sabe en Erlang. Prácticamente todo es visible. No hay, cuando digo todo es visible, no hay, no se pueden hacer muchas optimizaciones como de reordenar instrucciones o cosas que el usuario pueda observar, porque en cualquier momento tú puedes conectarte con un shell a la máquina que está corriendo Erlang y puedes hacer, puedes ponerte a observar qué está pasando en tiempo real. Entonces, si haces cierto tipo de optimizaciones, de repente lo que tú lees en código no es lo que sucede realmente luego. Entonces, ahí creo que somos un poco un lenguaje bastante único en el que tenemos que venir con ideas bastante inteligentes para poder hacer esas cosas. Y de ahí que no podemos ser tan performant como quien dice, como C o lo que sea, ¿vale? Pero en principio los benchmarks dicen que somos más rápidos, por ejemplo, en algunas cosas que Python y eso. Pero claro, esto siempre depende del tipo de benchmark que mires, tampoco se puede generalizar.

Y ahora mismo la hoja de ruta, viendo las últimas versiones de Erlang que se han ido sacando con los últimos años, ha habido un gran avance en lo que es la shell, ha habido avances en rendimiento, ha habido avances en distintas cosas que se intentan acumular desde Elixir, como nuevas instrucciones como Maybe, y nuevas instrucciones dentro del lenguaje. ¿Hay una hoja de ruta marcada de en las siguientes releases, en los siguientes años se va a trabajar en esta línea o se va decidiendo para cada versión?

Generalmente una vez al año y eso toca a, te lo diría pero es que todavía no ha tocado el meeting, por eso no lo sé. Pero en poco nos toca un meeting donde decidimos, ok, qué es lo que creemos que se podría incorporar a lo mejor en la siguiente versión. Y basado en eso se trata de hacer un esfuerzo en ver qué encaja. También he de decir que nosotros pues algunas veces no estamos solos también haciendo esto. Tenemos bastantes contribuciones sinceramente de la parte de WhatsApp. Nos ayudan mucho. Han ayudado, por ejemplo, con Dialyzer. Dieron un modo incremental de manera que Dialyzer no tiene que construir su, vamos a llamarlo, base de datos para luego consultar y hacer el static analysis, sino que lo puede hacer de manera incremental. Eso hace que, creo que dijeron que podía ser hasta un 60% más rápido si utilizas ese modo algo, ¿vale? Entonces, pues claro, tenemos también muchas contribuciones externas y que se hablan, como quien dice, con estas third parties o lo que sea para ver qué es lo que podría encajar. Sé que estamos colaborando con WhatsApp para introducir algo, pero no sé cuánto puedo decir, por lo tanto prefiero callarme esa parte.

Vamos, con la presión que hay últimamente en muchos proyectos y sobre todo en ciertos lenguajes, hay muchos lenguajes como PHP, Python y demás que están siendo programados en C, y la máquina virtual de Erlang es otro desarrollo que se hace principalmente en C, aunque después las librerías y todo lo que va por encima está escrito en Erlang. ¿Se ha pensado en algún momento en cambiar ese C por Rust, C o alguno de los lenguajes que van saliendo?

Se ha discutido, pero la cosa es que eso no es algo que se puede, que podemos hacer hoy en día, no con 15 personas, y donde a lo mejor la parte del runtime system igual la tocan 3 o 4 como mucho, vale. Entonces se ha discutido si a lo mejor algunas cosas. Quizás si hubiera alguna manera de hacer bien el linking entre Rust y Erlang, pues oye, igual tendría sentido. Pero actualmente creo que tenemos, miramos la línea de código, no sé si eran 180.000, 200.000 líneas de C/C++. Eso no hay quien lo porte sinceramente a Rust, ni es que no, vale. Y lo que tenemos ahora, como quien dice, es estable. Y mover algo a Rust, como quien dice, es encontrarte otro tipo de problemas en un problema que ya había solucionado. Porque va a tardar años en ver si eso tiene sentido. Entonces, la verdad que no. Se ha dicho, bueno, ya igual estaría bien si hay alguna cosa que se meta, pero también un lenguaje más que tienes que integrar en el equipo. Y Rust no es el más sencillo tampoco, creo yo, de introducir en un equipo donde 3, 4 personas a lo mejor son los que tocan la máquina virtual de Erlang. Entonces Yo diría que no. Está bien como dice de pensar, pero no, no va a pasar.

Y dentro de, o sea, estando dentro del equipo de OTP, o sea, tú tienes lo que es el feedback de mucha gente que está utilizando Erlang, que tiene algunas dudas, que tiene problemas y van reportándolos. ¿Os llega un poco el sentimiento de hay muchas empresas utilizando Erlang, se va incrementando, quizás decrementando? ¿Cómo se siente la comunidad y el uso de Erlang desde el equipo de OTP?

Pues es una muy buena pregunta. La verdad que desde nuestra perspectiva creo que quizá lo notamos más simplemente por la fundación de Erlang, el Erlang Ecosystem Foundation, porque tenemos conversaciones bastante con ellos y demás, y de ahí un poco se puede Se puede medio ver. La cosa es que yo creo que sigue exactamente estable, igual que estaba. No creo que haya cambiado mucho. Sí creo que el tema de elixir especialmente ha atraído a nuevas personas, a lo mejor de Ruby, a hacer elixir. Y eso creo que es bueno porque ahí hemos podido ganar. Pero mi experiencia en estos 4 años, que es lo que he estado empleado, Es que todo sigue exactamente igual. Y la cosa es que la gente que utiliza Erlang no hace mucha promoción de ello. Simplemente son gente más, a lo mejor, tranquila. Yo hago el trabajo y no tengo que estar poniéndolo en las redes sociales, ni tengo que estar dándole publicidad, ni nada. Entonces hay un montón de empresas que utilizan Erlang, pero no se dice mucho. Yo me enteré recientemente que Cabify, que creo que está en, tiene oficinas en España y demás, creo que utilizaban Elixir y yo no lo sabía hasta hace nada. Pero claro, ¿tú has escuchado alguna vez que mencionen mucho eso? Yo no, la verdad. Me enteré porque estaba mirando LinkedIn y de repente vi alguna pequeña cosilla de alguien que lo mencionaba. Pero es eso, la gente que lo utiliza no suele darle mucho bombo, como quien dice. Y Elixir, bueno, sí, porque parece que es un poco el nuevo hit around the block, el nuevo lenguaje. Y entonces a lo mejor hace un poquito más, pero si usas Erlang generalmente lo usas y ya está, y no mencionas mucho. Las compañías que lo usan son Cisco, WhatsApp y telecomunicaciones. Todo lo que tiene que ver con telecomunicaciones suelen usar generalmente de alguna manera u otra Erlang. Pero no suelen promocionarlo mucho tampoco. Entonces yo creo que está más o menos estable, ni para un lado ni para otro.

Y en base a los puestos de trabajo, porque siendo un lenguaje tan de nicho, o que se utiliza eso como tú has dicho, de forma muy callada y demás, se publicita poco. Las empresas grandes que necesitan programadores de Erlang, ¿os llegan a vosotros directamente para preguntaros y pediros consejo? ¿Se siente que haya una necesidad de programadores de Erlang? ¿Cómo se siente eso desde el equipo de OTP?

En nuestro caso, la verdad que yo creo que no recibimos mucho, pero principalmente, bueno, primero porque nosotros no podemos abrir, como te he dicho, creo que somos un equipo pequeño. Yo estoy viendo a ver si de alguna manera podemos contratar algunos más Pero como no ponemos posiciones, como quien dice, tampoco nos llega nada. Y luego la verdad que a mí, por lo menos personalmente, nadie me ha preguntado mucho acerca de este tema. Entonces la verdad que no. Sí creo que hay más posibilidades probablemente en Elixir. Y que las empresas grandes, algunas no tienen mucho problema en si tienes que aprender Erlang pero vienes de otro lenguaje funcional. Entonces creo que generalmente no hay mucho problema. Como digo, Klarna yo creo que probablemente sigue contratando gente con Erlang y te dicen, bueno, si no sabes pero estás dispuesto a aprenderlo, eso es lo que queremos, básicamente. Es que no tiene sentido empezar a pedir tecnologías de cero, en cierta manera. Y Erlang, como quien dice, en cuanto a la programación funcional, eso es estándar. Tú te puedes poner ahí a escribir Erlang en 2 días. Aprender obviamente las librerías y los conceptos más técnicos o de concurrencia o distribución, eso a lo mejor cuesta un poquito más, pero escribir el código en sí, la sintaxis y eso, eso es muy sencillito, no tiene tampoco tanto.

Hay muchas empresas que eligen a día de hoy Go porque piensan o se vende la idea de que Go tiene una curva de aprendizaje muy pequeña en la parte de distribución, en la parte de concurrencia e incluso en la parte de aprender el lenguaje. ¿Se ha pensado, porque Erlang, como has dicho, tiene también una curva de aprendizaje muy pequeña en lo que es el lenguaje, pero la parte de concurrencia y los conceptos quizás sea un poquitín más elevada que otros lenguajes que se dedican a lo mismo? ¿Se ha pensado en simplificar o ayudar en cierta medida en este sentido?

Pues la verdad que no. Pero estaría bien, como quien dice, si alguien, porque especialmente a través de la fundación de Erlang, yo soy muy activo ahí en el grupo de seguridad y en el de build and packaging, estoy escuchando por si alguien dice cosas, vale. Entonces, si alguien viene, como quien dice, con una sugerencia de cómo se puede hacer algo mejor a nivel de añadir una nueva sintaxis al lenguaje o cualquier cosa, Siempre puedes contactarnos porque estamos abiertos a escuchar todas las sugerencias del mundo. Y también puede abrir lo que es un EET, que es como una propuesta para expandir el lenguaje, y lo pones en el repositorio que tenemos, y ya de ahí pues tomamos la conversación, la verdad. Entonces, si hay algo que se puede mejorar, definitivamente estaríamos encantados de poder escucharlo para ver cómo hacerlo. Ha habido cosas que la gente ha propuesto y luego se han ido añadiendo, la verdad. Una de ellas, por ejemplo, fue— esta era muy sencilla, pero alguien del equipo de Equalizer de WhatsApp nos dijo si podíamos añadir simplemente el tipo dinámico este que mencioné antes para que ellos pudieran escribir dinámico, y quiere decir no sé cuál es el tipo, vale. Y fue como, ya, bueno, quiero decir, tampoco es como que hice un gran cambio, lo podemos añadir. Sabemos cómo hacerlo compatible con Dialyzer, que es nuestra herramienta. Por lo tanto, bueno, pues vamos a añadirlo. Otro cambio creo que fue cuando uno quiere coger dos listas y mezclar dos listas y coger un elemento de cada y hacer modificaciones con ellos. Eso se llama Zip Generators. Eso fue también un EEP que se escribió y bueno, pues se va a poner ahora en OTP 28, si no me equivoco. Entonces, cualquier sugerencia bienvenida, porque estamos para evaluar ideas, como quien dice, y si vemos que es factible y útil y no rompe nada, entonces igual se puede añadir, definitivamente.

Y aprovechando que has mencionado varias veces la fundación, ¿qué proporciona a la comunidad la fundación del ecosistema de Erlang?

Pues mira, la fundación en este caso Lo que hace es que hay diferentes grupos de trabajo que resuelven, como quien dice, problemas específicos. Tenemos la de Build and Packaging, que es la que se encarga pues de hacer que los builds de Erlang y lo que tú utilices, a lo mejor las acciones que utilizas en GitHub de Erlang y demás, pues que funcionen correctamente, vale. También tenemos, por ejemplo, otro grupo que es el de educación, que pues de vez en cuando pues requiere a lo mejor que la Erlang Foundation les dé este sponsoring, como quien dice, con cierta cantidad de dinero para poder pagar a lo mejor pues que minorías puedan ir a conferencias a aprender de Erlang y demás. O el de seguridad, que es sobre todo en el que yo estoy más metido. Y en el de seguridad, como quien dice, pues lo que queremos hacer es que Si eres alguien que trabaja con algún lenguaje de la máquina virtual de Erlang, ahora va a venir una cosa nueva que se llama Cyber Resilience Act, CRA, que exige que de aquí a 3 años tengas los productos que salen al mercado y tienen comunicación con el exterior, que básicamente es cualquier cosa, tienes que demostrar que tiene más seguridad, has empleado buenas prácticas y todo esto, vale. Y bueno, una de las cosas que estamos haciendo en el grupo de seguridad es, pues desde Erlang ahora damos lo que se llama un bill of materials, como una lista de recetas de todas las cosas que vienen con Erlang, con las dependencias y demás. Y tenemos que asegurarnos pues que si hay alguna vulnerabilidad tiene que ser reportada, tenemos que decir cómo la vamos a arreglar, es decir, todo está un poco más regulado De manera que si decides utilizar Erlang, pues Erlang digo porque es el que mantenemos nosotros, pero pues sabes que viene como quien dice sin ninguna vulnerabilidad reconocida, vale. Y lo mismo, se está apoyando desde el Erlang Foundation, se ha ayudado a Elixir y a Glimpse, los otros dos lenguajes que funcionan en la máquina virtual de Erlang, para que consigan ser, esto es un estándar ISO Open Chain Compliant, y eso lo que dice es que tratas de manera correcta las licencias que vienen en tu software. Es decir, no estás mezclando GPL con Apache porque son incompatibles. Si haces eso, Apache no aplica, aplica GPL y contamina todo lo demás, vale. Entonces pues vienes como quien dice con una serie de garantías que hace que digas, vale, pues oye, pues sé que estos proyectos están haciendo las cosas bien. Me puedo fiar de ellos, vale, y entonces los puedo utilizar. Y eso en algunos casos es bastante importante, especialmente en contratos que uno quiera hacer pues con el gobierno o cosas así, vale. Y si no, como mínimo tienes la garantía de que gracias a la fundación y al esfuerzo que se va poniendo, ciertas cosas van saliendo que te van a ayudar. El siguiente proyecto, por ejemplo, sería que como todo el mundo ahora de aquí a 3 años tiene que poder crear la lista esta de todas las dependencias que tienes en tu proyecto, esto, lo otro, pues se está intentando desde la Fundación Erlang hacer un poco de dar funds o dinero a ciertos mantenedores de proyectos para que sean capaces, por ejemplo, y no digo que este se esté haciendo en concreto, pero si tienes un proyecto en Rebar 3 pues que te pueda generar este tipo de lista, vale, con todas las dependencias que tú tienes, y comprobar que todo funciona como debería y que las licencias cumples con todas ellas y todas estas cosas, vale. Esto al final lo que hace es que si utilizas un lenguaje que corre en la máquina de Erlang, pues debido a que está en Erlang Foundation, pues sabes que tienes esas garantías y te va a ayudar básicamente.

Entonces, resumiendo, la fundación ayuda a temas de educación, minorías y el tema de empaquetado, seguridad. Según entiendo, cada workshop o cada grupo se dedica a un área completamente diferente y dependiendo del grupo pues ya tienen una dotación económica, son unos responsables y unas misiones específicas.

Sí, exacto. Sí, exacto. Dotación económica, eso es algo que tienen que ir los grupos pidiendo si les hace falta, vale. Y entonces se estudia desde el board y se decide. Pero sí, básicamente lo que se hace es tratar de apoyar, como quien dice, a que estos grupos sean autónomos y miren por los respectivos intereses que tienen en que funcionen las cosas en el ecosistema.

Pues vamos, ya llevamos casi una hora. Yo creo que ha estado bastante interesante todo lo que hemos estado comentando sobre Erlang. Espero que anime a algunos a acercarse un poco más al lenguaje. Que bueno, no lo habíamos dicho, pero creo que por sus orígenes Erlang guarda bastante relación con Prolog, y creo que ese puede haber sido también motivo del enamoramiento en Erlang venido desde la facultad.

Pues sí, sinceramente, la verdad que no está muy lejos, y el tema de que es funcional pues también ayuda un montón, sinceramente.

Pues, Kiko, ha sido un placer tenerte en el programa. Siempre me gusta sacar el tema de Erland siempre que puedo, y la verdad es que tenía esa espinita clavada porque con Brujo la verdad es que nos pusimos bastante negativos con el tema de las posiciones laborales y cómo está cayendo un poco Erland. Pero la verdad es que en esta nueva charla pues ya ha vuelto otra vez un poco el optimismo, ¿no? De que pueda haber más gente que se acerque a la fundación, que tome información y educación sobre cómo utilizar Erlang, que lo utilicen en sus proyectos personales, en sus proyectos empresariales, y que vuelva a resurgir un poco ese desarrollo simple y con carácter concurrente, distribuido y demás. Si quieres decir algo para despedirte.

Bueno, simplemente, si por lo que sea estás considerando si coger Erlang, Elixir o Klim, Has tomado la decisión correcta. Y si alguna vez te quedas un poco atascado algo, pues definitivamente puedes preguntar en el Erlang Forums o Elixir o Glean. Y si no, participa también en la Erlang Ecosystem Foundation. La verdad que nos hace falta más gente también que ayude y quiera participar, así que todo el mundo es bienvenido.

Pues lo dicho, muchas gracias por participar y nos vemos en otra sesión de codeadores. Gracias por habernos escuchado.