Elixir con Gonzalo Aller

Buenas tardes, estamos aquí otra tarde más en Codeadores para hablar sobre lenguajes de programación y con programadores que los usan a diario. Esta tarde he invitado a un invitado bastante especial, pues lo conozco de la lista de distribución de Elixir, donde es el administrador principal. Gonzalo, si quieres presentarte, y yo siempre hago la primera pregunta de cómo iniciaste en el mundo de la informática, así que si quieres ir a partir de ahí.

Vale, sí, sí, perfecto. Bueno, primero muchísimas gracias por invitarme, es un placer estar contigo hoy. Y nada, nada, ya responderte a la pregunta, yo empecé de una manera indirecta como muchas de nosotros, que fue en los 80 y con la Spectrum. Yo tuve un Gomas, el 48K, y después un Plus, y eso fue, digamos, que mi inicio personal, ¿no? Tuve uno previo un poquito antes, pero fue porque mi padre, el pobre, trabajaba en una subestación grande de electricidad de Endesa. Y él trabajaba, era una locura. Él tenía una mesa llena de teléfonos, debía tener por lo menos, no te exagero, como 40 teléfonos. Y a las menos 5, entre menos 5 e 5, le llamaban de todos los teléfonos. Tenía que coger el que tocaba por el sonido, no sé cómo lo hacía, coger unos datos al lápiz y después con una calculadora empezar a hacer cálculos durante un buen rato con todo lo que le mandaba. Evidentemente, ese era un sistema bastante manual y bastante duro. Era flipante verlo cómo tecleaba con la calculadora, era flipante. Entonces, digamos que en los últimos días, que él después, por desgracia, se tuvo que ir porque le dio una invalidez, pero bueno, justo el último año le pusieron un ordenador, un VAX además, que para mí el VAX tuvo después otras connotaciones que ya contaré. Pero bueno, en ese cacharro empezaron a hacer, pero tuvo la mala suerte que, claro, tenía que hacer su trabajo y además revisar el del ordenador. Entonces mi padre, el pobre, tenía mala fama, cogió mala, digamos que no le gustaban los ordenadores, le escogió un poco de tirria. Pero luego yo ya, mi abuela me regaló el Spectrum y empecé ahí a hacer cosillas. Después yo en realidad en la carrera ya fui más por las ingenierías, hice una ingeniería industrial, pero digamos que por vocación fui tirando, tirando hacia el tema de informática. Y luego pues monté una empresa, me metí con otras cosas, y mi vocación digamos siempre ha sido la informática. Y eso es un poco la razón de la por qué soy informático, porque estoy haciendo cosillas.

Entonces, cuando empezaste con la informática, yo creo que la mayoría empezamos con el ZX Spectrum y el lenguaje BASIC.

Eso es.

¿Qué fue lo que te llamó? Porque aunque hay mucha gente que empezó con minicomputadoras como el ZX Spectrum, Amiga y otros más, ¿qué fue lo que te llamó a hacer desarrollo y no utilizarlo como un jugador o persona usuaria normal?

Buena pregunta, sí señor. Porque yo ya, ya claro, yo tenía ganas, ya tenía ganas de a ver qué es esto. Aparte de los juegos que estaban bien, bueno, los primeros no eran muy buenos, pero jugabas, tenía ese rollo. También estaba esa parte de hacer algo, de que el ordenador haga lo que tú quieras, ese poder que sentías, que eso creo que al principio sobre todo lo teníamos todos. Joder, puedo hacer cosas yo y soy, me siento poderoso. Yo creo que esa fue la razón más importante. Y claro, cuando hice mi primer programita, que fue el primero, primero, primero que hice, fue en BASIC precisamente, Y fue una especie de tutorial educativo, fíjate tú, sobre física. Como estaba estudiando física, hice un tutorial de física que iba paso a paso explicando cosas. Era más de presentar. Pero el siguiente, que ya era un poco ya más complejo, fue también de química orgánica. Hice un— y ahí se vio un poco mi pasión, que es sobre todo por los temas conversacionales, curiosamente. Porque yo desde el principio siempre había estado flipando, y era una de las razones también por qué la informática me interesaba, porque yo casi de los primeros libros que leí fue 2001: Odisea en el Espacio, y HAL me flipaba, ¿no? HAL 9000 y todo eso. Entonces, claro, yo lo primero que quise hacer es hablar con el ordenador. Y una de las cosas que hice fue un, ¿cómo se llama?, de química inorgánica, un sistema que me pasaba de la fórmula a la fórmula dicha, o de la fórmula dicha a la fórmula, digamos, química, ¿no? Y funcionó muy bien, la verdad es que me felicitaron en el colegio, quedó muy chulo. Y luego ya, a partir de eso, empecé a hacer otras cosas más locas, ya empecé a juguetear con el código máquina, empezar a hacer cosas más potentes, más chulas, otros lenguajes. Me acuerdo que jugué con el Fortran, que estaba espectacular, con el Pascal, pero eso ya después, ya cuando empezó la cosa a cambiar y fue ya la explosión. Y lo primero que hice después ya en la universidad fue trabajar con un VAX VMS, y ahí ya lo pasé muy bien, lo pasé muy, muy, muy bien.

VAX, según tengo entendido, era uno de los sistemas que corrían con una versión de UNIX, ¿no?

El que yo usaba, había dos, efectivamente. Estaba la versión de UNIX, que fue posterior, y estaba el VAX VMS puro, que no tenía, era un sistema operativo propio, que era más rocoso. El sistema de gente, por ejemplo, de ayuda, era muy como una especie de árbol, ¿no? Podías poner help, show, y él te va explicando cada parte, ¿no? Entonces tú después sacabas los comandos del sistema y luego se usaba lo que tú necesitabas. Y era eso, rocosón, Feo, pero, pero muy interesante. Y luego ya sacaron versiones que funcionaban ya con UNIX. Yo después ya el UNIX realmente ya no lo usé con el VAX. El UNIX lo empecé a usar creo que fue con un HP 9000, creo también, y luego ya con Digital UNIX, con otros cacharritos, con Solaris menos. Pero vamos, que ahí ya se me abrió el mundo de UNIX. Y luego ya cuando apareció Linux, por supuesto, ahí con Slackware, ahí venga a divertirse, que eso fue ya otro mundo que se abrió gigante, ¿no? Lo de Linux ya fue la bomba. Pero eso fue posterior.

El uso de estos computadores, ¿eran en puestos de trabajo, en la universidad o en algún sitio, o directamente en casa?

Obviamente el Spectrum me lo compró mi abuelita, que Dios la tenga en la gloria, que ella me ayudó y siempre me dijo cosas. Pero en este caso el VAX era la universidad. Además de estos de compartido, teníamos unas terminales VT de color verde, y para los más, los más de la élite, digamos, les dejaban, y al final yo conseguí colarme, los de color sepia. Pero vamos, que te dejabas la vista ahí con el monitor verde, la VT100 era, creo, no, la 120, no me acuerdo. Era bastante duro, pero vamos, molaba, molaba mucho. Y luego imprimías, tenías la impresora que se repartía e imprimías los programas y los ibas mirando allí en el papelito de papel continuo. Estaba guay.

Hay un lenguaje que han nombrado que me ha llamado mucho la atención y la verdad es que quiero saber específicamente cómo es que llegaste a esa Forth.

Pues fue muy curioso porque fue de las últimas cosas, porque el Spectrum como duró tantos años realmente, porque fue un tiempo casi desde el 82 casi hasta el 87, 88, aún se usaba un montón más. Claro, al final había virguerías, había desensambladores, había lenguajes de diferentes tipos, y uno de los que me llamó la atención cuando apareció es el Forth. Entonces lo probé en su día y me encantó. El Forth está muy orientado a pilas, sabes, que tú pones algo, por ejemplo una pila, y vas en 2, 2, la sumo. Y empecé después todo eso que aprendí en aquel momento, lo usé mucho después con la calculadora HP-48, no sé si la conoces, y luego con la 48SX, la GX, que tenía lógica polaca inversa para funcionar. O sea, tú hacías, por ejemplo, 2, 2, igual, más, y sumabas en pilas. Entonces tú podías hacer swap, dup, podías hacer listas. Entonces mezclaba un poco ese lenguaje que tenía, el RPL se llamaba, mezclaba el FORTH original aquel con algo de Lisp también, de manipulación de listas, de meter cosas. Entonces hicieron un lenguaje muy bonito, muy bonito, que era interpretado. Luego sacaron un compilador para la calculadora, era flipante. Y luego ya estaba el binario, perdón, el ensamblador del RPL, que era para ese procesador que era súper raro. Era, se llamaba Saturn y tenía registros de 64 bits, era una cosa loquísima. Pero ahí también apliqué un poco lo que había aprendido del ensamblador del Z80, lo apliqué en ese procesador e hicimos cosas muy chulas de factorización de primos y cosas ahí Estaba muy bien esa calculadora. Yo también lo pasé muy bien, pasé muchas horas de disfrute con esa calculadora. Buen cacharro, era más gráfica, podías hacer de todo, de todo realmente.

Y bueno, ¿cómo llegas? Porque dice que estaba estudiando industriales. Y ¿cómo llegas de estudiar? Te tengo entendido, porque tampoco no soy muy ducho en ciertas ingenierías, pero sé que en industriales, por ejemplo, se utiliza mucho CAD. Supongo que la informática estará muy ligada para el diseño de todos los planos que se tienen que hacer.

En aquella época, por desgracia, como era hace muchos años, por supuesto, por desgracia, yo soy bastante mayor, pues en aquella época cuando yo empecé había que rotular con el Rotring, la madre que los parió. Y ya empezaba a haber, de hecho, empezar, empecé a ver en aquella época el AutoCAD, el 2.4, y usé yo el primero, que era con disquetes floppies de estos de de 5 y cuarto que se metía en el ordenador, dejando de andar metiendo, sacando un coñazo. Pero vamos, que ahí empecé a flipar mucho y ya empecé a usar en lo que es en la escuela ya ese tipo de PCs para ese tipo de cosas. Pero la asignatura, por desgracia, dibujo me la tuve que chupar con el Rotring, aunque era un coñazo. Ahí no se podía hacer zoom, no se podía hacer cosas que la gente ahora da por supuestas. Entre aquella te tenías que como comer. Y yo llegué incluso a la época del tiralíneas antes del Rotring, o sea que era duro el dibujo técnico. Lo del AutoCAD fue una maravilla. La verdad es que sí se agradecía. Y había después otros programas de la escuela de cálculo de estructuras. Yo, por ejemplo, en la escuela estudié Fortran. Fortran fue mi primer lenguaje, digamos, para estudiar, y me gustó también. Fortran fue un punto interesante también ahí de los lenguajes que he usado. Muy chulo. Luego ya después más C, Pascal. En el BACS usábamos Pascal también.

Y entonces, ¿cómo pasas a decir, después de salir ¿La primera, bueno, la primera o alguna de las salidas laborales que tuviste después de la carrera dio pie a que empezases más a programar que a cualquier otra cosa?

Pues como me encantaba y estaba un poco de becario haciendo cositas en el centro de cálculo de la escuela de ingeniería, lo que hice fue pues montar una empresa. Montamos una empresa porque era divertido y empezamos a hacer cosas ya desde el principio con temas de software libre, con Linux. Fuimos una empresa que empezó casi de las primeras pioneras de hacer software libre en España. Estuvimos con las guerras clon, fue muy divertido, lo pasamos muy bien. Y empezamos con eso y vendíamos ya sistemas con Linux en el 90, mira lo que te digo, en el 98, 99. O sea, fue hace mucho, mucho, y funcionaba, funcionaba ahí, y se podía usar en aquella época. De hecho, uno de los sistemas, por ejemplo, le contaba a un amigo el otro día, que hice fue Antes de internet teníamos que mandar, por ejemplo, notas de prensa a la presidencia o sitios de aquí a aquí. Entonces lo que hacíamos era, dentro, por ejemplo, un ordenador, le tenemos unas tarjetas de seriales múltiples que tenían salida, por ejemplo, en un caso en cada isla, por ejemplo, en Gran Canaria y Tenerife tenían 10 salidas seriales que se podían conectar a 10 módems RDSI con 2 canales cada uno. Entonces podías enviar simultáneamente las noticias del día por la mañana a todos esos sin usar internet. Hacías una conexión punto a punto, o sea, tenías un módem de un lado y un módem del otro, se conectaban y enviabas, y funcionaba súper chulo, estaba muy bien. Y empecé ahí con ese, ese fue mi primer trabajo profesional grande. Y ya casi desde cero tuve una disyuntiva: ¿qué lenguaje uso? Porque yo estaba haciendo cosas en Unix con C, pues estaba, pero era un poco low level, ¿no? Entonces estaba pensando que qué hacer, y justo había, hacía poco había aparecido el Python Y hacía un poquitín antes estaba el Perl. Y yo tuve los dos delante y tuve que tomar una decisión, ¿cuál uso? Y el que más me llamó la atención, y además ya tenía un poco más de tiempo, y sobre todo por estilo, el que me enganchó fue el Perl, fíjate tú. Y empecé, y ese es, por ejemplo, ese sistema lo hice en Perl y era la bomba aquello. O sea, podía hacer simultáneamente todo ese tipo de cosas sin ningún problema, funcionaba, nunca, nunca dio ningún problema, ningún fallo, y enviaba simultáneamente todas las cosas ahí en papelito a su impresora y Vamos, espectacular, funcionó de lujo. Entonces dije yo, va, Perl para adelante. Y ahí empezamos dentro de lo que es la empresa, empezamos a hacer servicios para bancos, para otros clientes, y usamos Perl. Y para la parte web, ModPerl con Apache, y nada, funcionaba muy bien. Después, ya con el tiempo, uno de los chicos que estuvo con nosotros, Esteban Manchado, que lo contratamos, que el pobre falleció recientemente, falleció hace 2 años, era un crack. Ese hombre murió jovencito, con 43 años. Pues el chico era un crack, ya te digo que era, era un tío extraño porque no era de ciencias, era de letras, pero hacía un código espectacular y tenía muy buenas ideas. Estaba muy bien, muy bien amueblado en su cabeza, ¿no? Entonces me convenció y me lo mostró en su día. Me dijo, me enseñó el Ruby y me dijo, mira, pues va a ser con Ruby, mira cómo es el programa, mira qué chulo. Y me enseñó además todo el tema de lo, el famoso podcast de para hacer un No, screencasts de hacer un blog, que además estaban de moda los blogs, y eran diminutos hacer eso. Digo yo, jo, ya está, me lo vendiste. Además, el lenguaje me gustó, y además era un, que luego lo hablaremos, para mí el Ruby es como una especie de heredero parcialmente del Perl. O sea, a Matzú le gustaba mucho, y siempre lo había dicho, que tenía mucha influencia de Perl. Todo el sistema de expresiones regulares, un montón de cosas las había cogido de Perl, otras cosas no. Pero vamos, que era un lenguaje que era una transición muy lógica entre nosotros y nos pasamos de Perl a Ruby muy fácilmente. Fue muy, muy sencillo y empezamos a hacer cositas en Rails, cositas también directas en Ruby para otros proyectos, no solo Rails, hacíamos cosas también directas y estábamos muy contentos. Siempre nos dio por saco un poco lo que es el rendimiento del Ruby, que nos hizo sufrir mucho y que tiene que ver con la siguiente iteración, digamos, lo que ya en la empresa no llegamos a hacer el cambio, fue posterior, pero vamos, que fue muy natural también pasar de Ruby Ruby a Elixir, que en este caso es casi, casi directo, porque Vadim pasó de ser el core developer de Ruby a pasar a generar Elixir cuando tuvo la gran idea. Porque ya sabéis la historia, ¿no? Él se leyó el libro este de 7 sistemas de concurrencia en 7 semanas, y cuando leyó lo de Erlang dijo, hostia, qué bueno es esto. Y cuando encima leyó cómo estaba hecho el Erlang, dijo, jo, va, si es que puedo hacer yo el lenguaje que yo quiera con la sintaxis casi de Ruby como yo quiera, pero género y te code para la máquina de Erland. Y así empezó Elixir. O sea, es como una, ha sido muy natural, muy orgánico en mi caso pasar de Perl, luego a Ruby y luego a Elixir. O sea, ha sido natural. Y para mí Elixir ya ha culminado y ha llenado todos los huecos, todos los problemas que, por ejemplo, tenía con el caso de Ruby, pues los ha llenado todas mis necesidades. Y la verdad es que estoy muy feliz, ya hablaremos por qué, pero hay un montón de cosas que tiene Elixir que son espectaculares. Y para mí, yo he llegado a mi tope de de peticiones, las cosas que necesitaba y no estaba contento, pues Ruby me las ha llenado. Fíjate tú, es curioso. Y ha sido bastante natural, bastante orgánico.

Entonces, la empresa que montaste por los 90 ha ido progresando y fuiste utilizando Perl, Ruby y después Elixir.

Al final se quedó en el Ruby porque en el año 2007 paramos de hacer, cuando la crisis, tuvimos que hacernos mucho más pequeños y paramos lo que es la rama de desarrollo. Entonces seguimos, mi socio siguió con temas de sistema, pero ya no, ya no seguimos desarrollando. Entonces en ese momento todavía, todavía no estaba evidentemente el Elixir, pero si hubiera estado yo lo hubiera usado, vamos, vamos, lo tengo clarísimo. Sin embargo, ya en otras cosas que hemos hecho y la empresa que estoy ahora, que estoy contratado, usamos Elixir a saco y vamos, lo mejor que he hecho en la vida, o sea, pero espectacular, o sea, espectacular. Y encima me llenó un huequito que tenía yo siempre porque siempre me ha gustado mucho el desarrollo web Pero las cosas no estaban, no me gustaba mucho. Y encima, tanto con los rollos de JavaScript, estas mandangas, no estaba nada contento. Pero cuando apareció LiveView en el horizonte, y mira que incluso yo estaba usando una librería antes de LiveView que existía, no sé si te acuerdas, no me acuerdo del nombre, pero yo ya estaba vigilando eso porque me pareció espectacular. O sea, el poder hacer todo el stack completo de lo que es web, y web reactivo y potente, hacerlo todo en Elixir o en un lenguaje, pero en este caso Elixir, que encima me encantaba, dije yo, ya está. Porque yo siempre he sido muy creyente, siempre me han gustado mucho más los sistemas más bien mainframe, o sea, tener las cosas en el servidor y el cliente que haga poquito. Ya desde la época del VAX/VS a mí me gustaba eso, o las terminales de estas, de las LTSP de Linux. O sea, siempre me ha gustado que la potencia esté en donde tiene que estar, en el servidor, y luego tener una buena infraestructura y conectarse. Evidentemente, después que que en Edge, digamos, tengas cosas, o en tu cliente, en tu ordenador, lo que sea, tengas cosas potentes, también está bien, y que se interconecten. Pero para servicio, yo siempre he sido mucho más creyente de que las cosas hay que centralizarlas en su sitio, y que lo mejor es la potencia tenerla controlada y no en un sitio que tú no sabes cómo se va a ejecutar nada. Entonces, esa parte me encantó. Y ya en este caso, cuando llega el Live View y con Porque yo antes usaba Phoenix, que me encantaba, por cierto, ya hablaremos después, pero claro, tenía que usar cosas en JavaScript, guarradillas. Me gustó mucho el Elm, por eso también evitaba el tener que estar usando JavaScript, que para mí JavaScript es una peste, es piojoso. También el PHP en su día lo evité como la peste. Ese tipo de cosas, el Java, que es una monstruosidad. O sea, todo este tipo de cosas yo he llegado a mis— evidentemente todo son opiniones, opinionated, ya sabes, pero es que creo que ahora tenemos un stack espectacular. Y encima no tienes que andar duplicando cosas, no tienes que andar con historias. Hicimos, por ejemplo, un sistema de control de tiempo para los coches de estos de cel, de la hora, de la hora, no, que está todo controlado con un servidor central. Y el tiempo que se lleva es centralizado, es todo el servidor. Entonces, en tu teléfono no hay nada, da igual que tengas mal la hora, el control es perfecto, no depende para nada de eso, y es reactivo. Ves el tiempo correr, o sea, espectacular, y en móvil. O sea que súper chulo, súper chulo, estoy súper contento. Yo ahora ya te digo que llegué al tope de, hombre, hay muchas más cosas que se puede hacer obviamente, pero vamos, que en lo que es el stack tecnológico yo ahora estoy feliz, feliz como una lombriz. Hay otros que están muy bien también, por ejemplo Go no está mal, u otro tipo de sistemas. En el caso, por ejemplo, de la concurrencia, era un problema que yo tenía, que empecé en Ruby. O sea, en Ruby yo necesitaba y usaba una librería que ahora no me acuerdo No me acuerdo cómo se llamaba, se me ha olvidado. Ay, Dios, la vejez. Pero bueno, estaba haciendo ñapas para poder hacer cosas concurrentemente y no funcionaba mal, pero era una ñapa, era una alegría. Pero claro, cuando descubrí esto y vi que además Erlang, yo lo conocía ya de oídas, veo que funciona tan bien, digo yo, qué pasada. Porque a ver, los sistemas que se hacen, y sobre todo web, de APIs y tal, una de las cosas importantes, y más ahora que son de multiprocesador multinúcleo, tienen que ser concurrentes. O sea, en informática la concurrencia es importantísima. Yo siempre pongo de ejemplo que la gente compara el ordenador del Apolo, el proyecto Apolo para ir a la Luna, dice, lo comparan con una, con un móvil, y que el móvil es millones de veces más potente. Pero en realidad están comparando peras con manzanas, porque en realidad para lo que era ese ordenador, el del Apolo, era perfecto. Es mejor, de hecho es mejor, funciona mejor que un teléfono, un móvil programado como es ahora iría mal, no funcionaría bien, porque el sistema de Apple era de tiempo real, estaba muy bien programado para hacer las cédulas que tenía que hacer. De hecho, se parece mucho al sistema de Elixir. Y en el fondo es que la arquitectura y cómo funcionaba ya en los años 60 era mejor que mucho de lo que se hace ahora en un móvil que cuesta una pasta, pero no por la potencia de la memoria ni el procesador, sino porque estaba bien hecho. Y estaba hecho con memorias de ferrita y apenas tenía procesador, pero era virguero porque estaba bien pensado. Y ahí la genia fue la chica esta, Margaret Hamilton, que casi la conozco, por cierto, porque una vez en Boston y fui vecino de ella y no lo sabía. Pues para mí esa es una héroe, es uno de los héroes de la informática, y es encima mujer, que encima ahora tiene más mérito por todas las cosas de STEM y todos estos rollos que están. Pero vamos, que la chica hizo una barbaridad programando aquello, y era un sistema que llevó perfectamente a los hombres a la Luna. Dio el error aquel famoso, pero era porque el ordenador, pero él se reseteaba, se ponía en marcha, hacía todo el scheduling, y usa el mismo sistema en el fondo que usa Erlang, por ejemplo, y Elixir, que es el tema de dejar que las cosas fallen y corregirlas. Que es brutal para temas de tolerancia a fallos, que en informática no se habla mucho normalmente y es importantísimo. O sea, un sistema tiene que funcionar, no se puede caer o quedarse sin memoria o hacer una excepción y quedarse todo tirado. Tiene que funcionar, los sistemas son para que funcionen. Y eso para mí fue también otro gran descubrimiento, todo el tema de los supervisores, todo el tema del procesado, el sistema funcional, la inmutabilidad, todo ese tipo de cosas que hacen mucho más predecible y mucho más fácil hacer que un sistema complejo funcione. Y una de las cosas también que me gustaron fue el tema de la concurrencia. Porque, a ver, en un ordenador pasan muchas cosas a la vez y tienes que programarlo de una manera que te quepa en la cabeza. Y el sistema de actores, que es el que usa, que es el que usa Elixir sobre todo, es de los 70. O sea, es un sistema teórico muy antiguo, pero que está bien pensado para cómo funciona, para cómo funciona Elixir. Y es que es uno de los temas, además, porque Alan Kay lo decía, que es que el la verdadera orientación a objetos no es la que tienen los que se supone que son los de orientación a objetos. Son más parecidos a los de estilo de Elixir, estilo de comunicación de mensajes. Porque Alan Kay decía que un sistema de comunicador que se comunica entre mensajes es un sistema realmente de objetos, un objeto. Es realmente la mejor definición del sistema de objetos, pero la gente lo ha pervertido y lo ha llevado a otros caminos, que es el famoso que decía Armstrong, uno de los fundadores de, ya sabes, uno de los creadores de Elixir, y de, perdón, de Erlang, y luego ayuda en Elixir, decía que la orientación a objetos era una locura, que te tenías que, para coger un plátano tenías que cogerte el gorila y la jungla entera. Y es verdad que cuando te pones a pensar y comparas unos con otros, la carga mental cognitiva que tienen los sistemas grandotes de estos de objetos comparado con lo que los sistemas de, que tú ya conoces, en funcional y la separación de funciones y la composición, es totalmente mucho más asequible a la mente. Y yo siempre digo que es un elixir, y estos lenguajes son para gente que va entrando en años, porque oye, la CPU, la humana, también va poco a poco quitándose recursos. Y esto te permite tener en la cabeza y manejar cosas de una manera manejable. Entonces, manejarlo, me repito, pero vamos, tú me entiendes, o sea, hace que te quepa en la cabeza y que puedas separar los proyectos, las tareas y los sistemas en partes pequeñas, que es la mejor manera en ingeniería y en de hacer las cosas. Haz las cosas que se partan en soluciones pequeñas y luego las vas montando entre sí. Y esa filosofía, que también es muy de Unix, de tener pocas herramientas, muchas, o muchas herramientas, interconectarlas entre sí y componer, todo eso hace que puedas hacer cosas mucho más complejas con un nivel razonable cognitivamente para poder trabajar con ello. Porque es que hay muchos cambios de paradigma, sobre todo porque es verdad que funciona y todo eso, pero es que es un cambio, y en mi cabeza pegó un cambio muy grande, que es pensar la programación. La gente la ve un poco estilo Scratch, cosas imperativas, no pasa esto, pasa esto, pasa esto, hay un bucle. Pero es que si piensas realmente las cosas como son, y por eso a mí no me gusta mucho el Scratch para los niños, las cosas no funcionan así. Son más bien yo tengo, hago algo, y cuando me pasa esto hago esto. Es más reactivo, es una cosa más proactiva. Entonces la forma en que funciona una aplicación en mi cabeza ahora de Elixir o una aplicación de ordenador es totalmente más natural. Son cosas que están hablándose entre sí, no No es una, y encima tú sabes que puedes observar cómo están funcionando los procesos, cómo se apagan, cómo se encienden. O sea, la forma en que se piensa una aplicación en el ordenador es diferente con Elixir que con Python, que con C, que con otros lenguajes, porque ahí sí que son mucho más imperativos, van paso a paso, pero es, o incluso los ves como conceptos de objetos que tienen como clases. O sea, esa forma de pensar para mí es ofuscarse Y sin embargo, el ordenador, lo lógico es que funcione como funcionan las personas, que es que tú necesitas hacer algo, se lo pides a alguien para que te ayude y ya está, y lo haces y te comunicas. Es que es mucho más natural.

Yo creo que al principio la orientación a objetos que se implementó en los primeros lenguajes, como por ejemplo C++, vino a ser como era, que obviamente no era exactamente como Alan Kay había puesto en su libro The Smalltalk como intercambio de mensajes y pequeños elementos que interactúan entre ellos. Y claro, él lo veía como tú has dicho, como un mundo natural en el que todo es concurrente. Y entonces tiene, tiene un poco más de sentido el cómo se crea un software a cómo se vive en el mundo, es casi como un reflejo. Pero una cosa bastante curiosa que me di cuenta cuando estaba utilizando Ruby y Ruby on Rails es que Hubo un momento, una versión, según recuerdo, creo que en principio era todo, lo encapsulaban todo en clases, y llegó una versión en el que quitaban las clases y ponían módulos. Es decir, todo eran funciones y ya no había objetos, eran módulos. Y tú metías dentro del controlador que creabas, tenía que ser un módulo y ya no era una clase. Y entonces pegaron ese pequeño cambio. Y entonces a mí ahí me hizo pensar en esto que estabas tú comentando de la orientación a objetos. Pero yo también recuerdo que en Elixir al principio intentaron, aunque no consiguieron afortunadamente, meter los objetos. Y aprovechando esto, ¿qué fricciones encontraste cuando tuviste que cambiar de Ruby a Elixir? Porque claro, los cambios son bastante notables.

Sí, porque Ruby está orientado, tan orientado a objetos, que un número es un objeto. O sea, ahí todo es un objeto, es la exageración de los objetos. Aunque esa parte, por ejemplo, de Ruby me simpatizaba, ya ves tú. O sea, él se lanzó de cabeza y dijo, esto soy de objetos, pues objetos a tope. Y ahí en esa parte me gustó, porque por ejemplo en el caso de Perl y Python siempre eran cosas medio mezcladas, pero en el caso de Ruby se lanzaron a la piscina totalmente. Eso estuvo bien, mira tú. Pero es verdad que luego al cambiar, cambió todo el paradigma, cambió todo. Pero claro, como yo lo primero que hice en Elixir ya fue con Phoenix, de repente me di cuenta de una cosa muy chula que es que Rubén Reis en general siempre ha sido muy oscuro y muy mágico, y pasaban muchas cosas. Era lo de, lo de, ¿cómo se llama?

Magia negra.

Sí, magia negra, hay mucha magia. Entonces, claro, cuando funciona bien, pero cuando no funciona. Una cosa que me gustó de Fénix es que Fénix lo puedes desmontar pieza, y ahí McCord ha hecho un trabajo espectacular, Chris lo puedes desmontar pieza a pieza, nivel a nivel, y ves exactamente de manera transparente toda la maquinaria de esa cosa, que es gigantesca, tiene de todo, pero lo ves, es como un reloj que es transparente y que puedes ver las partes, puedes quitarlas, puedes cambiarlas, puedes componerlas. A diferencia de Rails, que yo no me quería ni meter, había gente que se metía, no le quedaba otra, pero aquí era un agujero negro gigante. Sin embargo, Phoenix es una cosa muy parecida porque también es MVC y todo esto, pero es totalmente transparente, es otra bestia totalmente diferente. Y además que está pensada para que le enchufes cosas, lo del plug ya ya te lo dice, los plugs. O sea, está muy bien arquitectónicamente. Phoenix es la bomba. Y hay gente que, por ejemplo, este tipo de frameworks no les gusta, pero a mí, en el caso, por ejemplo, de Phoenix, me parece que han hecho un gran trabajo, muy, muy gran trabajo. También después para hacer migraciones, cambios, cosas. Ha sido para mí uno de los proyectos más limpios y más chulos que— y conozco mucha gente que le encanta Phoenix. La forma que está hecho está espectacular. Y luego, encima de Phoenix aparece el tema de LiveView y ahí, boom, ahí la cabeza me dice, guau, qué chulada, espectacular. Para la gente que no conozca, el LiveView lo que hace es usar el DOM, digamos, del navegador, lo conecta por WebSockets al backend, aunque esté usando, y los deltas de cambio de DOM los hace el servidor. O sea, tú realmente en el cliente apenas haces nada. Entonces hay gente que dice, hola, pero eso cargas el servidor, qué locura, mejor que se haga en cliente. Y yo digo que no, que no, que el mejor sitio es el servidor, que hay un montón de optimizaciones que se pueden hacer. Y además el Elixir y el Erlang van tan bien que ni se enteran. Es mucho mejor que lo haga y lo preprocese todo el servidor y que te dé el numerito que tiene que ser. Y encima las transferencias de datos, a veces, como son solo los pequeños cambios que hay, si no hay muchos cambios en la pantalla, es que es más rápido que andar mandándose JSON y tener un bicho ahí peludo hecho en TypeScript o JavaScript que esté ejecutando cosas. O sea, es una guarrada. Y encima tienes que programar en 2 lenguajes, en TypeScript JavaScript, JavaScript, lo que sea, y luego en el backend que hagas. Que claro, la gente como quiere hacer todo lo mismo usa Node, o sea, es llevar el problema al servidor. Qué mal. O sea, para mí eso fue bueno. Node ha sido otro de los grandísimos errores de la informática que he tratado de evitar siempre como la peste, con un palito. Y yo lo que hice fue al revés. Yo lo que quiero es dame un entorno en el que solo programo una vez la lógica de negocio y después lo presento como yo quiero y ligerito. Y eso me permitió en su día que se ejecutaran cosas muy potentes en teléfonos, en relojes, en cacharros chinos chiquitines de IoT que apenas tienen pantalla pero aguantan un navegador. Solo con que no aguante un navegador y un DOM ya lo tienes todo. E incluso hay soluciones ahora con, con que existen ya también para cosas muy chiquitinas, estilo, ¿cómo se llama? En NERVS, para NERVS, exacto, que lo pones. Y en NERVS, pero yo en NERVS al final he acabado usando, que eso es otro killer project que tenemos que mencionar, he acabado usando LiveView porque es lo mejor, porque es que va todo empaquetado. O sea, tú en NERVS tienes todo metido en una Raspi o en un cacharro en un kit todo lo que necesitas para hacer lo que quieras de web, de ejecución de temas de binario, de procesos, lo que quieras. Y todo metido en el sistema operativo en 50 megas. O sea, es flipante, flipante. Lo de NERFS es otro gran proyecto killer. Ese es un killer que va muy bien. Yo lo he usado muchas veces y estoy súper contento. El, bueno, ahora se está poniendo de moda y se va a poner muy de moda el tema de WebRTC, el Membrane, el Broadway, todo este streaming, porque funciona espectacular para temas de comunicaciones, va muy bien. De hecho, es lo mejor que hace Elixir. De hecho, uno de los subsistemas, por ejemplo, del Mozilla Hubs, que es una pena, pero es un proyecto que está ahí en el aire porque Mozilla lo dejó, pero la gente lo quiere mantener, todo el subsistema de comunicaciones e interno está hecho en Elixir. No sé si lo sabías. Y la parte de visualización pues es JavaScript por el CJS, pero vamos, que la parte lo que es de comunicaciones e interna de funcionamiento es casi todo Elixir y funciona de lujo. Es que es brutal. Brutal. Y todo el subsistema ahora que están haciendo, VRTC, para funcionar y hacer cosas. De hecho, hace poco en lo del BIM Europe pusieron, lo hizo, lo hicieron con este sistema, con lo que está haciendo la gente de Membrane, que está espectacular lo que están haciendo. Entonces ese es otro proyecto que va a ser muy, muy interesante. Y otro que ese es más pero a ver qué pasa con ello, es lo de NX y todo esto de los sistemas para temas de machine learning, que es muy interesante lo que hizo el Moriarty, muy, muy interesante. Y está metido Balint también, y tiene sentido porque así coge también, coges mercado de lo que está de moda ahora, que es la inteligencia artificial. Está muy bien, está muy bien que estemos ahí metiendo la pata, pero metiendo la pata en el sentido bueno. Pero vamos, que a ver, a ver qué tal va, porque es verdad que lo que más currado está en otros lenguajes, en Python y todo esto, pero está muy bien que también el Elixir podamos usarlo, porque también tenemos todas las grandes cosas de nuestro ecosistema, todo el tema de concurrencia, todo el tema de sistemas distribuidos, aplicarlo también a sistemas de machine learning. Eso puede ser una buena combinación, ya veremos. O sea, hay proyectos ahora que están muy, muy interesantes, muy, muy interesantes.

Hablando un poco sobre el Elixir, sobre todo para Ya has comentado que ha sido tu cambio desde Perl a Ruby y ahora en Elixir. Sí, parece que de momento no se ve nada más en el horizonte, pero cuando tú lo utilizas en tus desarrollos y vas utilizando los frameworks que hay, ¿qué dirías tú? ¿Que hay algo que pueda estar faltando o que echarías en falta de otros sistemas que hayas utilizado? O lo ves ya que ha llegado a un pico que ha sobrepasado a otros sistemas?

Yo lo veo muy maduro, muy maduro, porque es verdad que evidentemente tiene menos librerías que otros lenguajes, pero también es verdad que hasta hay veces que usas las librerías de esos lenguajes. Yo he usado cosas de Python, usado cosas de R, cosas de C. En ese sentido, por ejemplo, ha mejorado bastante el soporte. Ya sabes, el tema de los NIFs, que tú puedes hacer una extensión de una manera relativamente limpia. Es uno de los grandes problemas, quizás el único problemilla que hay, pero ludillo es el tema de las NIFs, que pueden matar la máquina de Erlang. Pero bueno, también se arregla porque puedes rearrancar la propia máquina. Pero bueno, la cuestión es que eso no estaba muy fino, pero se ha ido mejorando mucho. Ya hay maneras dentro del OTP, de lo que es la máquina virtual y el sistema de Erlang, que se está solucionando ese tema. Y una cosa buena es que la gente está usando, por ejemplo, Rust o Zig o lenguajes así que permiten un control mucho más concreto y correcto de la memoria y de los procesos. Entonces ya, por ejemplo, en Rust es muy raro que el NIF falle o que te deje el sistema en un estado malo, porque aquí siempre lo que hay que evitar es que el sistema pare y no funcione. Siempre hay que de alguna manera que se reinicie, que se arregle, que se ponga en marcha, que nunca pare, que dé servicio. Entonces, en ese sentido, Rustler, por ejemplo, ha sido un gran, gran proyecto también para mantener eso. Pero a futuro hay un montón de cositas que se están haciendo muy interesantes de temas de puertos, de usos que que completan eso que comentaba yo, que puede ser una deficiencia, que a lo mejor te falten librerías de temas. Pero es que yo últimamente ya casi casi de cualquier cosa encuentro conectores, o sea, ya es raro que no los encuentre. Y si no, se puede hacer fácilmente, o si no, se hace un wrap. O sea, no me siento que me falte, o sea, en mi caja de herramientas me siento que lo tengo completo. Y últimamente te comento, por si a lo mejor no lo sabías, uno de los pequeños sitios que me quedaba por colonizar eran los microcontroladores, no, el, por ejemplo, el ESP32 y cacharros de estos, no, que hasta hace poco pues estaba, tienes que hacerlo en C o a lo mejor en MicroPython, que es medio juguetito comparado con eso. Pero ahora hay una gente que han hecho una versión de chiquitina de la máquina virtual de Erlang, han hecho un UTP modificado para ESP32 y han conseguido una cosa que no hace ni MicroPython todavía, que es usar los 2 procesadores. O sea, ya es SMTP, ya es SMP O sea, tú puedes ya en Elixir o en Erlang programar cositas que usen los procesadores de un ESP32, cosa que todavía Python no hace bien, imagínate. Entonces todavía está verde, le quedan cosas. De hecho, lo quieren integrar en el proyecto con Nerves también, están hablando, ¿no? Y eso tendría la maravilla, es que puedes tener desde lo más chiquitito, desde un ESP32, tener tu Elixir ahí programado, hasta pasando por las Raspberry, que eso ya funcionan perfectamente, y luego de ahí para arriba cualquier cacharro, hasta el servidor más gordo, ya todo funciona funciona con Elixir. Y ya después se puede interconectar entre sí. Por ejemplo, unas cosas que faltan, y estoy ya con ganas, es que le ponga el tema del sistema de nodos de Erlang, que lo puedas usar también en el microcontrolador. Porque ya ha llegado a ese punto, ya soy feliz completo. O sea, ya tengo todo, todo el stack, el edge, digamos, desde lo más pequeño a lo más grande, al servidor más gordo. Ya, ya puedo programar y hacer cositas en Elixir, que me mola. Que ojo, no significa que decir, por lo que pasa siempre, que sea la panacea y sirva para todo. No, por supuesto que no. Hay otros lenguajes, ya te digo que en Rust combina muy bien, el C combina muy bien también con él. Y hay cosas para las que no son temas, por ejemplo, de que te puedes usar, no, pero que para juegos, por ejemplo, directos, no tiene sentido. Pero hay un montón de cosas que cubre, que te permite programar de una manera muy alto nivel, muy, muy elegante, y te permite pues eso, poder hacer cosas que serían muy complicadas en lenguajes normales, en C, C++, lo que sea. Sin embargo, en Elixir, por ejemplo, el tema de concurrencia es mucho, mucho más controlable. Incluso que, por ejemplo, que en Rust todavía le queda un poquito para estar bien para temas de concurrencia. Go, por ejemplo, en ese sentido es un buen lenguaje. Go, las gorrutinas estas están muy bien, está muy pensado. Pero Go no tiene Tolsys, el OTP, que es un regalo del cielo, porque hay un montón de trabajo hecho por miles de personas, miles de programadores, que te lo dan gratis gratis para que lo uses desde Elixir y Erlang, o Glimpse, otros lenguajes que también no hemos mencionado. Hay otros lenguajes también que compilan a Vim, que eso es una gozada, o sea, es que eso es una gozada.

Volviendo otra vez al tema de tu trayectoria, o sea, tanto tú como otros de los que conoces pasasteis de Perl, Ruby a Elixir, pero ¿crees que sería más complicado saltar desde algún otro lenguaje diferente o incluso aprender directamente de Elixir? ¿Qué recomendaciones darías para gente que se quiera introducir en Elixir?

Pues fíjate, yo soy en eso bastante diferente a lo que la gente, porque normalmente la gente dice, no, empieza con Python, es muy clarito, o a la gente, a los niños, enséñales Scratch y todo esto. Y yo, fíjate, yo me parece que es, me parece que es malo. O sea, esa manera de aprender cosas o informática es, no es, es perjudicial. O sea, es muy curioso eso. O sea, yo pondría a la gente ya desde cero, yo si fuera yo, yo ya pondría desde el principio a que usaran programación funcional. Fíjate lo que te digo, o sea, hacerlo al revés, porque yo creo, yo creo que es superior el paradigma, es superior. Hay gente que los pone al mismo nivel, yo no lo creo. Yo creo que la programación funcional es mucho más rigurosa, es mucho más razonable, es mucho más humana, fíjate, como te digo, que la otra. La otra es un poco más artificial, es más artificiosa. Aunque parece, te ponen el ejemplo del coche con las ruedas, el camión con las ruedas, los objetos. Al final parece que es una cosa lógica, pero empiezan a hacer trampas rápidamente y se va todo al garete muy, muy, muy rápido. O sea, de lo que te prometen a lo que al final tienes no se parece. Sin embargo, en el caso de los lenguajes funcionales, casi siempre han sido bastante rigurosos, desde Haskell, que es bastante, ya sabes que Haskell es muy duro porque es muy matemático y está muy, muy, se sale un poco de lo práctico. Pero aquí en el caso del Elixir y Erlang han conseguido un equilibrio entre lo que es lo bueno de lo funcional y lo bueno de sistemas prácticos que tú necesitas. Entonces han conseguido un equilibrio de algo que tiene sentido, que cabe en la cabeza, que es lógico. Y es que yo le enseñaría a los niños antes, antes que Scratch, por ejemplo, les enseñaría, que a mí me gusta además, es un juego que se llama Lightbot, que es un jueguito en el que tú programas un bot, un robotito chiquitín para que ilumine cosas, ¿no? Es sencillo, pero rápidamente entra el concepto de hacer funciones. Y las funciones, porque tienes una stack muy chiquitín, vas a hacer cositas. Entonces con eso rápidamente tú le das conceptos que son bastante lógicos. Hace esto varias veces, sabes, empiezas desde cero en con lenguajes ya más declarativos, cosas que tú quieres hacer y que cuando las necesitas las usas. Es otro paradigma, pero es mucho más lógico. Yo cuando me enseñaron matemáticas, al principio recuerdo que nos enseñaban temas muy abstractos como el tema de diagramas de Venn y cosas así, que la gente en su día decía, pero ¿para qué les enseñan a los niños esto? No tiene sentido. Eso es más práctico, es la aritmética, 1 1, reglas. Pero también lo que no ven es que las matemáticas, lo más potente de las matemáticas, no son las malditas reglas. Eso lo hacen ordenadores, ¿qué más da? Eso es aburrido. Lo bonito de las matemáticas es la abstracción, es la conceptualización, es lo chulo. Y eso es precisamente a lo que los niños, el primero se enseñan a sumar 1+ 1, esas reglas, pero eso es un bucle o pasos, pero eso no es lo importante, no es lo importante. Un ordenador le tienes que decir que haga una cosa y que lo haga, eso es lo importante. Entonces definirle de una manera lógica ya cómo se solucionan problemas desde el principio. O sea, yo creo que es más un tema tema de pensamiento, de solucionar, de casi algorítmica básica, pero orientada a solución de problemas. No empezar por al revés, que es casi ver, bueno, vamos a hacer la receta pasito a pasito. No, es mucho más potente que una receta, es mucho más, el ordenador hace cosas mucho más, y se ve claramente que hace cosas mucho. Ahora ya estamos llegando a los niveles de la IA y todo eso, que yo tengo mis opiniones, pero la cuestión es que hemos ido subiendo de nivel. Y a mí me parecía muy natural cuando leí el libro, en lo que hacía Hal. Hal era perfecto, le preguntas una cosa, te respondía. Eso para mí me parecía el ordenador perfecto, que no lo hemos conseguido todavía para nada, pero para mí era el interfaz ideal. O sea, el ordenador hace lo que yo le digo que haga. Y eso es lo que estoy intentando siempre con todos los sistemas que uso. Yo siempre, yo tengo un dicho, que el mejor código a veces es el que no se echa. Cuanto menos, más pequeño, más terso. Por eso me gustaba el Perl, porque el Perl en una expresión regular hacía lo que hacía un programa en C en 100 líneas, y una vez lo entendías era perfecto. Había gente que lo acusa de oscuro, pero depende, porque el Perl se puede hacer muy oscuro o muy clarito, te deja. Python es siempre igual, trata de ser uniforme, pero Perl iba por el camino de la diversidad. Entonces tú puedes programar en Perl, que yo lo he hecho, se puede programar en latín, latín clásico, y con la, y con ojo, con la aritmética sin cero se puede perfectamente, o en Klingon o en lo que quieras, o súper clarito, incluso más clarito incluso que en Python. Es un tema que te deja a ti la libertad, tú haces lo que tú quieras. Por eso me gustó, siempre me gustó eso. Y luego ya tanto Ruby como Elixir ya han tenido otros caminos, pero también tiene su sentido. O sea, en el caso de Elixir, tú lo ves, ves Ruby, ves Elixir y se parecen así de lejos porque la sintaxis es parecida, pero internamente su forma de pensar y todo el paradigma es completamente diferente. Y ese es el salto que hay que dar. Por eso yo creo que desde el principio a la gente habría que enseñarles de otra manera. No, no le enseñes a paso, paso, pasito, y hago esto, hago aquello. No, no, no, no. Enseñar a hacerle funciones, funciones que hagan cosas, incluso funciones recursivas que hagan cosas. Eso que lo tiene el Lightbot, ya enseguida te saca la recursión. Es que la recursión es una cosa que debería darse desde párvulos, porque es la lógica, la cosa más lógica del mundo. Aplica esto a sí mismo. ¡Ay, qué chulo! Y funciona de coña. Ya sabes lo que se dice, ¿no? Que iterar es humano y hacer la recursión es divino. Porque eso es verdad, es la manera más lógica y más elegante matemáticamente de solucionar ese problema. Encima tiene sentido. Parece que es una cosa súper complicada, pero no. Una vez lo piensas y lo aceptas, es que tiene todo el sentido. Coño, si esto se puede aplicar aquí, ¿por qué no aplico sobre sí mismo? Y eso es un concepto hiperpotente. A mí me gusta mucho en informática el concepto, y en la vida también, el concepto de que que con poquitas reglas, sistemas con poquitas reglas te permiten hacer lo que tú quieras. Y es verdad, fíjate que con un electrón, un protón y un neutrón, la que se puede liar. O por ejemplo, cuando apareció el wiki, que yo flipé, me encantó. En el 2000, cuando Cunningham sacó el C2, dije yo, hostia, o sea, flipé, me hizo boom la cabeza. Qué cosa tan sencilla, tiene solo 2 reglas: poder editar una página y poderla linkar entre sí. Una cosa tan chorra la potencia que tiene. Bueno, mira, ahora Wikipedia, mira, es un sistema espectacular y en realidad es súper chorrón. Pues esto es lo mismo. Cuantas menos cositas, menos piezas móviles tenga un sistema, más poder te da. Y en el caso de Elixir, tienen, o Erlang también, tiene un montón de unas pequeñas cositas como el tema de la, de la, el pattern matching, que es una especie de expresiones regulares súper vitaminadas, ¿no? Porque te permiten cazar estructuras de datos, no solo ya cositas chiquitinas. Entonces, todos esos conceptos llevados, bien llevados, y con el tema de la composición, por ejemplo, de funciones, que es brutal. Tú, es la primera vez que en un programa lees de una manera como si estuvieras leyendo el orden en que se procesa un dato, sabes. El pipe, el pipe es un invento infernal que se lo han querido poner a otros lenguajes, hasta en JavaScript, en Python, porque es que es una idea buena. O sea, tú tienes un un dato, y es además es de Unix el pipe. Tengo un dato, le paso a otro, lo proceso por la tubería, cambia, luego lo paso a otro, luego pasa a otro y me da un resultado. Es que es lógico, es lo más lógico del mundo, es cómo se hacen las cosas. Tomadme esto, Pepito, le hago un cambio, hazle otro cambio, y se van procesando así. Y luego encima, como tienes varios agentes haciendo cositas a la vez, los interconectas, se ponen a hacer cosas para, para concurrencia. Es un espectáculo, es que espectáculo. A mí me encanta, es que me encanta. Para mí fue un cambiazo, ya te digo, fue, fue un abrir los ojos, decir qué cosa más bonita. Y me gustaría que mucha más gente abriera los ojos así, pero bueno, poco a poco. Porque ya te digo que es un cambio no solo de paradigma de programación, sino paradigma de pensar en los ordenadores. Porque yo ahora me imagino, yo por ejemplo tengo un cosito, tú sabes que por ejemplo en el móvil uno de los grandes problemas que yo tengo tenía y tuve en su día es que tú tienes GPS, pero programáticamente en mi servidor, yo estoy en un servidor, un programa, yo no sé dónde estoy yo porque Google no tiene ninguna API, no tiene ninguna API para saber dónde estás tú desde un servidor. O sea, en el móvil sí, pero en un servidor no. O sea, yo no puedo preguntarle a Google dónde estoy, no se puede, no existe, por seguridad también supongo. Entonces, ¿qué hice yo? Yo pues puse en, hay una cosita para Android que por cierto es una cosa también que adoro, se llama Termux, que es como tener un pequeño Linux dentro de una Android con todos los paquetes, tiene APT, es la bomba. Bueno, pues yo tengo ahí mi versión de Elixir, la última, pitufándose, ejecutándose sola. Y lo que hace este bichín es que cada cierto tiempo comprueba dónde estoy con el GPS y lo guarda, pero está interconectado con un servidor mío, con un nodo Erlang, está conectado y le está diciendo cada poquito, chivándole, dónde estoy yo. Entonces yo puedo procesar en cualquier sitio, ya en la nube con mi servidor, cosas que yo esté haciendo sabiendo cómo estoy el GPS. Y le puede mandar un mensaje, por ejemplo, de vuelta al móvil que me avise: oye, que estás en la tienda no sé qué, eso lo uso bastante, y acuérdate que tienes que comprar tal cosa. Pues me lo avisa el móvil, me salta una alarmita que me avisa de que tengo que hacer algo. Y lo hizo el servidor, no, y se lo dijo a la máquina que tengo en local. Con dos aplicaciones a nivel de aplicación que se están hablando entre sí, qué brutal. O sea, el, por ejemplo, todo este rollo Kubernetes, microservicios, toda esa mandanga, es una, eso es una locura. Muchas veces es mucho más barato hacerlo todo a nivel de aplicación y tener los sistemas separados, que además se pueden, está pensado para eso, que se hablen entre sí y ejecuten funciones. Yo, por ejemplo, ahora quiero ejecutar un tema de IA en mi ordenador gordo de la casa, lo tengo conectado al servidor también, y a mi móvil o lo que sea. Yo le digo, oye, necesito procesar esto, se lo mando a la aplicación a nivel de aplicación, y él va, lo mira, y me va a mi ordenador, mira si está encendido, le pregunta, lo coge, y a nivel de aplicación hace todo eso, ejecuta funciones y resulta el resultado donde en el móvil, en el ordenador de casa que tiene GPU, en lo que sea. Es que está pensado para sistemas heterogéneos, que es lo que hay ahora, y encima multinúcleo. Una de las cosas malas que tiene Go es el recolector de basura, o Go Java, por ejemplo, que tú tienes un servicio, va muy bien, está súper bien, súper rápido, pero de repente algo pasa y se pone ahí a hacer algo. ¿Qué pasó? Y luego sigue, ¿no? O sea, entonces la latencia a veces en el servicio puede verse afectada por el recolector de basura porque es único. Sin embargo, por ejemplo, el caso de Elixir, que es una de las grandes cosas que tiene, y Erlang, claro, es que la recolección de basura se hace por los agentes, cada procesito chiquitín que tiene. Entonces yo lo comparo a echarse un pedo gordo, o sea, por ejemplo, el Go echa un pedo, o el Java, y se para a echar el pedo. Y este, sin embargo, lo que hace son burbujitas, o sea, tiene como micro, micro gestores de recolección de garbage por proceso. Entonces tú no te enteras. E incluso el scheduler busca el procesador que está más vacío y va echando pedidos en el procesador, y tú no te enteras nunca. Entonces la latencia y la curva de servicio que da un servicio hecho en Erlang o Elixir no tiene nada que ver con la de un lenguaje incluso compilado como es Go, que en teoría es más rápido. Pues da mejor servicio. Fíjate, es curioso, incluso con el mismo hardware, una cosa hecha en Elixir que en Go. Es muy curioso eso. Y eso que Go está optimizado, está compilado, tiene alguna ventaja, que es hacer un ejecutable pequeñito, pero luego a la hora de la verdad, para ejecutar cosas, tiene esos pequeños, ese detalle tan tonto. Entonces el Elixir, digamos que echa burbujitas, echa pelitos ahí, y nunca se nota. Y encima usa todos los procesadores que tiene a mano. Y si no llegan procesadores, pide otra máquina, y si hace otra máquina, la que sea. Y se habla entre sí a nivel de aplicación. Que eso es brutal. Porque en los otros casos hay que hacer pues redes, que si corvas, que si historias, que si gRPC, o sea, maneras de conectar más complejas que te hacen los sistemas más complejos. Hombre, evidentemente esto hace complejo también el sistema, pero si lo llevas bien, lo llevas controlado y hablas entre sí y tienes supervisores que te mantienen todo el tema en marcha, que es otra cosa buena que tiene Elixir y Erlang, pues estás feliz. O sea, tienes aquello funcionando y feliz como el pupa. Una cosa en Nerves, por ejemplo, que me flipa es que yo desde mi terminal en mi ordenador, o hasta en el teléfono móvil, me conecto al nodo Nerves y hablo con él en Erlang. Voy, me conecto al nodo y le pregunto cositas en el lenguaje, en Elixir, y me contesta. Es brutal, es brutal, es brutal. De hecho, el de LATOM todavía no lo tiene, pero le pusieron un RPL en Lisp. O sea, tú le puedes programar en Lisp y él te responde. Espectacular. Y otro sistema que tiene es chulísimo, Elixir, que ahí gana Erlang, que ahí estuvo, ahí estuvo súper, súper bien Balint, que él quería eliminar mucho boilerplate de Pred, y lo que hizo fue crear un sistema de macros brutal. Entonces, hacer metaprogramación y hacer cosas en Elixir es una gozada. De hecho, eso es muy icónico, aunque no parezca. Es como Lisp, o sea, tú puedes programar todo. De hecho, en Elixir está programado, en Elixir casi todo. Es que es chulísimo, y eso es muy potente a la larga. Permite pues hacer un montón de cosas, permite hacerlas mucho más concisas, mucho más tersas, mucho más controladas. También es verdad que es una potencia que hay que, es lo que dice, que no todo el mundo lo tendría que usar todo el tiempo, pero te permite hacer mejoras y cosas súper potentes, súper chulas. Otra cosa buena que tiene el Xill, por ejemplo, es la manipulación de binarios. Puedes hacer pattern matching de binario, o sea, la manipulación, que es una cosa interesante, y para AtomVM es genial. Tú puedes coger estructuras de C o lo que sea, coger ahí y manipularlas de una manera mucho más lógica y natural con todos estos sistemas. Entonces ya te digo que desde lo más chiquitín a lo más grande se pueden ir hablando, interconectando, hablando entre sí, y usar esto. Y que luego hay que hacer programas, usar programas en Python, o sea, programas en C, en Rust, en C, también te intercomunicas o los usas directamente. O sea, tienes todas las ventajas y muy pocas de las desventajas, que es lo bonito de Elixir y de Erlang y todo esto, todo este ecosistema.

Estábamos comentando antes de que, o sea, cuando tú estuviste haciendo los trabajos y montaste tu empresa en 2007, tuviste que cerrar, y entonces empezaste a trabajar en otra empresa externa, supongo, con Elixir. ¿Cómo va el mercado laboral por donde tú te mueves según qué tipo de lenguaje, así como Elixir o Ruby u otros?

Bueno, muy buena, muy buena. Si te fijas en el TIOBE, yo he estado siempre vigilando últimamente, y Elixir, por ejemplo, es uno de los mejor valorados para pago. O sea, en EE.UU., por ejemplo, o en el extranjero, si sabes bien Elixir y es Erlang te pagan muy, muy bien, e incluso mejor. O sea, es uno de los lenguajes que tiene mejor pago, y encima es uno de los lenguajes también que a la gente le gusta más. O sea, que está muy bien valorado. Pero luego, a la hora eso de encontrar trabajo, si realmente lo controlas y empiezas a funcionar bien, hay trabajo. Sí, sí que hay en remoto, hay empresas que ofrecen trabajo en Elixir y que se puede, se puede perfectamente hacer de manera remota, o in situ también los hay. Pero no es de los lenguajes que tiene más paro. No, porque también hay gente que lo está tomando. También ha tenido un crecimiento lento, pero ahora hay empresas grandes, Discord y otras, que lo quieren, que lo usan, y se está cogiendo tracción. E incluso en la parte web cada vez tiene más, y hay más gente ya que te lo pide. Por ejemplo, Cabify en España está probando Elixir y contratan a gente que sepa Elixir, que sean buenos. O sea, ahí hay casos, hay casos de éxito. Y eso es un lenguaje que es interesante conocer. Si además conoces otras cosas, pues perfecto, dentro de lo que es la caja de herramientas. Pero si consigues un trabajo con Elixir, una de las cosas más interesantes que yo veo, es mi experiencia, es que todo el que empieza a trabajar con Elixir muy raras veces acaba mal o acaba disgustado. Siempre, siempre, las veces que yo pregunto, tengo algunas excepciones, pero bueno, confirman la regla, siempre han sido eso, qué gozada, qué bien estoy, y más quiero, más quiero, más. O sea, está creciendo, está creciendo. Y es un lenguaje que compensa conocer, aunque luego uses otras cosas, pero solo para el aprendizaje, para cómo te estructura la cabeza y para un montón de cosas que luego puedes usar tú internamente. Merece la pena, merece la pena.

Ya te digo, a mí ya se me han acabado las preguntas. Yo creo que hemos dejado muy claro lo bueno que es el I Ching y que todo el mundo debería aprender, y sobre todo que deberían empiezas a aprender con lenguajes funcionales.

Sí, sí, sí, sin duda.

Si quieres decir algo para finalizar.

Bueno, yo siempre comparo, Elixir es un lenguaje nuevo, moderno, joven, con alma vieja, porque en realidad tiene todo lo potente de años y años y años de experiencia de gente muy buena, porque el Astro era un crack, y mucha gente, o sea, hay gente muy buena que ha dedicado horas y horas y horas y horas para que tengan un alma potente con una cara y un tooling espectacular. Mix es una virguería. Hay un montón de cosas que molan y que están muy bien, y que además coexisten muy bien con lenguajes estilo Rust y cosas que están apareciendo ahora. O sea, tú no estás, no tienes por qué verlo como esto y nada más. También eso es una cosa importante. Yo a lo mejor parezco muy talibán de Elixir, pero es porque me encanta, porque lo uso, porque me vale. Pero he usado muchos lenguajes, los conozco y sé sus limitaciones. Y en el caso este, para los tipos de, por ejemplo, yo me dedico mucho a chatbots y temas de comunicaciones y chats y cosas así. Para eso es perfecto, es que es el mejor, sin duda el mejor. También, por ejemplo, este, Akka, y estos usan modelos de actores, pero usa máquina virtual de Java y tiene otras cosas. O sea, Go tiene lo que comentábamos antes. Ahora, en temas de comunicaciones, por ejemplo chat, lo mejor, lo mejor que se puede usar sin duda es Elixir, sin duda, pero no lo dudes. Entonces, en mi caso, pues es que encuadra perfecto. Pero luego ya para otras cosas más esotéricas, bueno, ya puedes tener diferentes niveles de uso. Pero para lo que yo uso más, por ejemplo, para temas de APIs, temas de web, de verdad feliz. Para temas de IoT, para temas de control distribuido, para temas de tolerancia a fallos, para sistemas que no se tienen que romper, porque un sistema lo mejor es que no se rompa, obviamente, ¿no? Pues eso, para mí ahora no es por talibán, no es porque sea religioso, sino porque es que de verdad a mí me cubre las necesidades que yo tenía, me las cubre perfectamente, y encima puedo usar otros. Espectacular. Yo uso Python mucho, uso Perl incluso todavía, y el Perl 6 es una gozada, tiene cosas muy chulas de gramática y tal, pero al final, en el día a día, cuando tienes que usar el arma principal, para mí es Elixir, sin duda. Y que aunque uses otros lenguajes, lo conozcas, te va a venir bien, segurísimo.

Y bueno, ha sido un placer tenerte aquí y hablar largo y tendido sobre elixir. La verdad es que has dicho algunas cosas, más la mayoría ya las conocía, pero muchas otras la verdad es que viene bien siempre escuchar de gente que lo usa a diario, como el tema de nerfs y membrane y otras cosas que has mencionado. Es muy interesante. Y lo dicho, ha sido un placer tener la charla contigo y nos vemos la semana que viene con otra charla más. Muchas gracias y hasta otra.