Erlang con Brujo 🧙‍♂️ Benavides

Pues buenas otra vez, estamos aquí en otro capítulo de Codeadores. Esta vez me acompaña una persona que nos va a hablar de un lenguaje que no es tan mainstream como Java, PHP u otros lenguajes que hay en la esfera, sino esta vez hablamos de un lenguaje que viene de Suecia, Erlang, y tenemos con nosotros a Brujo Benavides. Buenas, Brujo.

¿Qué tal, Manuel? Un gusto estar por acá.

La primera pregunta que yo suelo hacer siempre es, ¿cómo te introdujiste tú en esto de la computación, en la programación y demás? ¿Qué fue lo que te hizo clic para decir yo quiero dedicarme a esto?

Lo mío viene de muy pequeño porque mi padre era uno de los primeros ingenieros que se recibió en la Universidad de Buenos Aires en Argentina, y cuando yo tenía algo así como 10 años vinieron un grupo de hippies con una camioneta a la escuela primaria a la que yo asistía, que era pública, y ofrecían enseñar a programar. Traían sus propias Commodore y enseñaban BASIC de Commodore a quien quisiera aprender después de clase, como un extraescolar. Y mi padre por supuesto me anotó a mí y a mi hermano, y empecé a programar y me gustó. Entonces, 1 o 2 años después, mi tío, que es doctor en matemáticas y trabajaba en ese momento en Estados Unidos, me trajo de Estados Unidos una computadora, me llevó de Estados Unidos una computadora a Argentina, y en esa computadora se podía programar en QBasic, así que empecé con eso también y nunca más abandoné. O sea, a partir de ahí, ya desde pequeño que me gustaba escribir programas y seguí escribiendo programas el resto de mi vida. Después conseguí que me pagaran por hacer lo que me gusta, lo cual estuvo muy bien. Así que nada, hice eso desde que era pequeñito, programé Visual Basic, programé después también para trabajar C#, y mucho tiempo después en la universidad aprendí programación funcional. Y en algún momento una empresa necesitaba un programador Erlang, yo no sabía Erlang pero sabía programación funcional, y Y entonces me postulé para el cargo y me aceptaron, por suerte, y me enseñaron. Y así conocí el lenguaje en el que trabajo ahora, digamos.

¿Cuándo fue exactamente más o menos cuando empezaste con Erlang?

En 2010. Sí, a principios de 2010, que fue el mismo año en el que terminé la facultad. O sea, el último año de la facultad y el primero de trabajar con Erlang fueron el mismo.

Cuando dices que empezaste a programar y ya no lo dejaste, ¿tenías en mente programar algo específico como juegos o aplicaciones?

Cuando empecé, empecé con juegos. Y no sé si conoces QBasic, pero viene con 2 jueguitos cuando instalas el QBasic. Ahora no sé, pero en aquella época venía con 2 jueguitos: el Nibbles, el de las serpientitas, y uno que eran 2 gorilas que se tiraban bananas unos a otros y explotaban las bananas. Y las primeras cosas que hice fue cambiarle la efectividad a la banana del gorila, cosa de que en lugar de romper el edificio más próximo rompiera como la cuadra entera, todo un montón de edificios todos juntos. Y este, porque me molestaba mucho perder, porque era un juego donde ponías el ángulo y la velocidad y tenías que ser bien, bien certero para pegar. Y este era los partidos eran larguísimos porque hasta que encontrabas el ángulo justo te cambiaba el viento y perdías toda la coordinación que venías haciendo. Entonces decidí darle más impacto, cambiar la banana por una bazuca básicamente. Y después también programé algunos juegos que los hice yo. Y más adelante me di cuenta que con el daltonismo, yo soy daltónico, me iba a costar bastante entrarle por ese lado a la cosa. Entonces empecé a trabajar en empecé a desarrollar más bien aplicaciones y cosas, los sitios web pero la parte del servidor, digamos, cosas de lógica y algunas cosas más así. Y ya cuando estaba antes de empezar la universidad tuve la suerte de cursar computación en una escuela secundaria de Argentina en turno noche, con gente que va a estudiar no porque lo mandan sus padres sino porque realmente tiene ganas de ir. Y que viene al colegio con problemas reales de la vida real. Y entonces ya parte de lo que aprendíamos mismo en esos cursos lo usábamos en las empresas en las que trabajaba esta gente. Yo por suerte no trabajaba, pero ellos sí. Entonces ya hacíamos software para remiserías o administración de contables, ese tipo de cosas.

Cuando empezaste a trabajar para esta empresa y te enseñaron Erlang, porque ya vas con Erlang desde ese momento hasta la actualidad, ¿Qué fue lo que más te llamó la atención de este lenguaje? ¿Qué fue lo que te cautivó para decir este es mi lenguaje de elección?

Primero que me gustaba que era un lenguaje de programación funcional. Yo ya conocía Haskell, pero tenía muy claro que Haskell no era para el mundo real, digamos, porque hay algunas aplicaciones que va bien, pero yo quise hacer, hice mi tesis, de hecho la tesis de licenciatura la hice con Haskell. Y ya era un programa muy pequeñito, un intérprete de Haskell con algunas otras variantes específicas, y correrle la suite de tests que tenía me llevaba una hora. Y entonces era claro que si yo quería practicar, si yo quería trabajar de esa manera con Haskell en el mundo real, iba a estar complicadísimo. Pero Erlang, si bien escribir programas era parecido a Haskell, la evaluación, la ejecución, todo era como muy, muy superior y mucho más cercano a lo que yo venía trabajando en mi trabajo. Entonces como que tenía lo mejor de los dos mundos, era muy bueno para programar de la manera en la que a mí me gustaba, del estilo de forma en la que yo trabajaba, pero además era muy bueno porque el código que generaba lucía como a mí me gustaba que luciese, que era programación funcional. Entonces era lo mejor que se podía encontrar, digamos. Tenía sus propias dificultades, pero por otro lado tenía soluciones a problemas con los que yo todavía no me había enfrentado y que tampoco quería enfrentarme, como era la distribución, la tolerancia a fallas y demás, que ya como venían resueltos, gracias a Dios, ahí los tenía y no tenía que ponerme a pensar en eso.

¿Y qué cosas consideras que fueron una fricción o que no te gustaban tanto del lenguaje, por lo menos en aquel momento, e incluso alguna que se haya arrastrado desde ese momento?

Y lo de siempre, lo que todo el mundo, cualquiera que le preguntes eso de Erlang te va a decir lo mismo, el tooling. No tiene nada, no tiene nada de herramientas para el usuario Erlang. O sea, está hecho para que trabaje la gente de Ericsson como le gusta a la gente de Ericsson y listo. Cuando yo empecé, de hecho yo venía del mundo de Microsoft, .NET, C#, qué sé yo, y en Microsoft el problema que tenía en ese momento es que no te podías alejar de sus herramientas, tenías que usar Visual Studio, tenías que usar la IDE y las cosas, los compiladores y los servidores y las bases de datos y todo lo que ellos te daban porque si te alejabas un poquito terminabas mal. Al mismo tiempo, de la facu yo venía con unas máquinas con Linux y qué sé yo, y era muy molesto tener que pasarme a una máquina de Windows para poder trabajar, mientras que en mi casa tenía una Mac. Entonces cuando llegué con Erlang me dijeron, no, no, Erlang anda de hecho mejor en la Mac. Y entonces dije, ah, buenísimo, entonces ahora, ¿qué herramientas uso? Y me dijeron Emacs. Y yo digo, pero no, amigo, Emacs no. Iba a tener la Mortal Kombat Era las fatalities del Mortal Kombat, una tras otra, un problemón. Entonces pasaban esas cosas, pasaba que cuál es la herramienta para compilar Erlang, no hay una herramienta para compilar Erlang, cada uno lo compila a la manera que se le ocurre. Ahora existe Rebar 3 y hay unas herramientas bien armaditas, pero en aquel momento era te encontrabas un nuevo proyecto y vaya uno a saber cómo se compilaba. Cuando tenía documentación. Cuando no tenía documentación ibas a preguntarle al autor porque no había mucha vuelta. O también tenías, existía Dialyzer que es una herramienta para hacer chequeo de tipos. Piensa que yo venía de lenguajes tipados y Erlang no tiene tipos, o sea tiene tipos suaves y yo venía de lenguajes con tipos bien fuertes. Entonces yo quería volver a hacer, quería aplicar las técnicas que yo sabía, chequear los tipos y demás, y la respuesta era siempre como, y existe Dialyzer, pero salvo que seas griego y puedas consultarlo con Kostis, que es el autor, difícilmente puedas entender lo que te está diciendo. Más allá de que tarda como una hora en revisar un proyecto pequeño. Y así toda la experiencia de desarrollador de Erlang era siempre pelear contra las máquinas, contra el código, contra el compilador. Era una pelea constante. Lo lindo que tenía es que el resultado de eso era súper estable. En mis experiencias anteriores era muy fácil llevar cosas a producción y se rompían todo el tiempo. Pasé a Erlang y era un poco más complicado llevar herramientas, llevar cosas a producción, pero una vez que estaban en producción estaban ahí y duraban meses, años, hasta que a alguien se le ocurría cambiar algo. Entonces nada, tenía eso de malo, así que las herramientas eran limitadas para el desarrollador.

Con la entrada de Elixir y otros lenguajes sobre BEAM, la máquina virtual de Erlang, ¿crees tú que esto se está paliando un poco y están yendo ya en esa dirección de conseguir un buen tooling?

Exacto. De hecho, una de las principales razones de José para crear Elixir era poder meterle velocidad a eso, o sea, poder dar una mejor experiencia al desarrollador sin tener que esperar a todo el ciclo de desarrollo de OTP, ¿no? Que uno plantea la cosa, que se arma todo un documento, que qué sé yo, tardas 3 años en formalizar algo que pueda acercarse a OTP. Ahora quizás es un poquito más rápido, pero tampoco es tanto más rápido. Mínimo un año hay que esperar para que haya una cosa nueva en Erlang. En cambio, en Elixir es como que salen las cosas más fácil. Y si bien tenía otros objetivos también, parte de los objetivos de Josep era ese. De hecho, tuve la posibilidad de hablarlo con él cuando eran las primeras versiones de Elixir, y él decía que Elixir no era perfecto, pero que tenía la suerte de que, bueno, cualquier cosa que no puedas hacer en Elixir la haces en Erlang, no hay problema. Y mientras tanto tienes buenas herramientas para trabajar con los problemas básicos, digamos, tienes los primeros pasos todos resueltos, que con Erlang no sucedía así.

Ah, sí, eso ya sería la parte que menos gusta de Erlang. Si tuvieses que darle, si alguien tuviese que introducirse ahora en Erlang, ¿Qué recomendación le darías?

Bueno, que miren, he dado una charla en castellano y también en inglés hace no mucho tiempo, una a la que tú le has puesto el título por suerte, que habla de todas las nuevas herramientas que hay en Erlang. Unas cuantas he desarrollado yo, pero otras han desarrollado otros, como la gente de WhatsApp, por ejemplo, que acercan, que acortan la brecha, ¿no? O sea, al día de hoy no vale la pena arrancar Erlang con el libro de Joe Armstrong o de Francesco, que arrancan de lo básico de Erlang y hasta que llegas a tener algo que puedas verlo te comes medio libro, digamos. Conviene utilizar las herramientas que son más de ayuda al desarrollador, hacer proyectos con Rebar3, usar las herramientas, los plugins de Rebar3 que sirven para formatear el código, para chequearlo, para validarlo y demás, y eso hace que la experiencia sea más amena. Y lo mejor que tiene en general la BIM en realidad es la comunidad, que tenemos una comunidad de gente muy abierta y con muchas ganas de ayudar a los que recién llegan. Entonces siempre, desde hace ya muchos años, mi consejo para la gente que empieza con Erlang es que no se decepcione, porque seguro que los primeros problemas que se enfrente van a parecer muy difíciles, que se meta en los foros, que se meta en el Slack y que pregunte, porque el 99% de las veces alguien le va a responder y alguien le va a ayudar. Es así.

También, si tuvieses que cambiar algo del lenguaje, o sea, si tú dijeras puedo cambiar lo que sea, me dan carta blanca de cualquier cosa específica del lenguaje y dices puedes cambiarla, ¿qué sería?

Digamos que me dan la carta blanca para romper la compatibilidad hacia atrás, ordenaría todos los parámetros de todas las funciones como hizo Elixir, compatibilizaría todos los módulos de todas las herramientas que vienen en la librería estándar de Erlang y las pondría en el mismo orden que las puso Elixir, digamos, el primer parámetro es lo que importa y después vienen las demás cosas, cosa de que utilizar una función no requiera ir a consultar la documentación, que sea más intuitivo para el desarrollador dónde va cada cosa. Y además que si el estándar se mantiene permita crear herramientas como los pipes de Elixir u otras cosas así que requieren que el lenguaje sea estable en ese sentido, digamos, ¿no? Que esté estructurado correctamente. Lo que pasa es que, por supuesto, cambiar funciones del módulo de listas de Erlang es una locura porque está en todo, todo código Erlang tiene eso, entonces no se puede, pero bueno, paso a paso, qué sé yo. Ese es mi principal, es algo con lo que ya aprendí a vivir y es algo que yo siempre digo, desarrollo Erlang hace 10 años, cada vez que voy a usar las funciones de recorrer listas voy a la documentación y me fijo el orden de los parámetros, es así, nunca se va a quedar en mi memoria cuál lleva cada cosa en qué lugar. Mala suerte.

Recuerdo una charla de Mariano y Robert Birding en el que Mariano le preguntaba que cómo veía que cada nueva versión de Erlang agregaba algo nuevo pero al mismo tiempo rompía algo que ya estaba bien.

Te digo que rompe bastante menos, rompe bastante menos que otros lenguajes. Yo he trabajado en .NET Y era año tras año tirar cosas porque le contaba creo que, no sé si lo dije en una charla o en la charla de pasillo en la última conferencia a la que fui, pero en .NET era necesitan un framework para hacer AJAX, era en aquel momento, y el que había era un desastre. Entonces le habíamos hecho un montón de parches para que pudiera funcionar como nosotros queríamos. A la siguiente versión todos esos parches no eran necesarios porque Microsoft lo había arreglado. Genial, pero rompió 10 cosas más. Entonces teníamos que hacer otros 10 parches nuevos y así. El ciclo de programación de .NET era cada año perder un mes en reemparchar todo lo que Microsoft había roto esa vez. Con Erlang, por suerte, no me pasa. Actualizar versiones en general anda suave. Quizás no le aprovecho todas las cosas nuevas, digamos mi código del día a día todavía no usa Maybe tanto como podría, que es una cosa que apareció hace 2 o 3 años, pero el código que está escrito funciona y está bien, y pasó del 23 a la 24, 25, 26 sin problemas.

Entonces, para adentrarse, porque habíamos comentado que echarle un vistazo al tooling sería lo ideal para comenzar, Pero, ¿qué otros recursos en base a libros, tutoriales, cursos y demás recomendarías para adentrarse en lo que sería el lenguaje en sí? Pues estamos ya claros que el tooling es la parte fundamental y sin tooling no vas a ningún sitio. Pero una vez que ya te manejas un poco las herramientas para ver las características del lenguaje, pues como tú has dicho, partiendo de C#, es un lenguaje muy diferente. Dice, ¿cómo cambias ese mindset?

Este, yo en general nunca recomiendo mucho libros, sino más bien trabajar, entrar a hacer cosas con sus propias manos. Tengo más de, más de uno, o sea, varias personas que han empezado así conmigo, que me han dicho, bueno, ya más o menos entiendo cómo va esto de Erlang, ¿Qué puedo hacer? Y uno de ellos, por ejemplo, ahora está haciendo, está llevando a Elvis, que es el linter de Erlang, a su siguiente versión, un pull request por vez. Otro de ellos creó ya un par de plugins para Rebar 3. ¿Quién más? No sé, había alguno otro que hizo una base de datos en memoria, no una base de datos base de datos, sino un key-value store en memoria y así. La Erlang System Foundation, por suerte, tiene todo un grupo de gente que nos dedicamos a educación y en parte lo que hacemos es mentorship, o sea, trabajamos como mentores de gente que tiene ganas de empezar a hacer cosas. No todo el mundo se va a sentir lo más cómodo haciendo este tipo de cosas, pero Es algo, hay muchas cosas, mucho conocimiento de cómo trabajar en Erlang que no está escrito en ningún lugar, o que si está escrito hay que leer mucho hasta encontrarlo, digamos. Hay mucha filosofía de cómo escribir buen código que todavía no está documentada en ningún lado. Entiendo que la gente de WhatsApp está tratando de ir por ese camino ahora, está haciendo, generando un montón de documentación sobre cómo escribir Erlang prolijamente y bien y funcionalmente y demás, pero estamos muy lejos todavía. Entonces lo mejor que se puede hacer es contribuir en algún proyecto donde esté, donde el que está manteniéndolo sea alguien que está activo y escuchar, escuchar los consejos, escuchar las recomendaciones de esas personas, de los que ya tenemos unos cuantos años en esto, y aprender de eso. Es lo más útil porque te lleva después a poder ser, actuar como mentor en un futuro de otras personas llevando los mismos consejos a los demás.

De los grandes proyectos de Erlang que me vienen a la mente, como Illa Verde, CoachDB, esas son grandes piezas de código que están allá, son código abierto, puedes echarle un vistazo.

Exacto.

Había alguien que decía, creo que era Richard Stallman, que para ser un gran escritor de código hay que leer mucho código. ¿Tú recomiendas tomar algunos de estos proyectos para leer el código y saber cómo se escriben ciertas cosas o prefieres más empezar haciendo?

El que generalmente recomiendo porque me encanta cómo está escrito y documentado y todo y testeado sobre todo es Mongoose IAM, el de Erlang Solutions. Está súper prolijo ese código y de hecho la gente que trabaja ahí es de esa gente que le encanta que se esfuerzan en que el código sea entendible y claro y demás. Más allá de que además sea performante y funcione y todo, son personas que están muy enfocadas en que el código pueda ser leído. Entonces leer Mongoose IAM es una buena cosa, es algo que educa y además resuelve problemas complejos. Porque quizás yo te puedo decir que algunos de los proyectos que tengo yo también están lindos para leer, digamos, pero no vas a aprender tanto porque no resuelven problemas tan grandes o tan complicados como los que resuelve Mongoose AM. Entonces a mí Mongoose AM me parece genial ese código. Otro que me gusta mucho pero que hay que tomarlo con calma porque tiene sus años y tiene muchas cosas que están hechas a propósito para bancar distintas versiones de Erlang y qué sé yo, entonces es se vuelve tedioso leerlo el código, pero una vez que lo entiendes va acelerando y va bien, es el de RabbitMQ. El de RabbitMQ es un código muy completo que también resuelve problemas bastante, bastante complicados, que está bien escrito. Hay que tenerle paciencia al código porque tiene muchas macros y tiene muchas divisiones en el código para poder soportar distintas versiones y demás. Pero también está súper prolijo, es muy interesante de analizar y de leer.

Creo que curiosamente de RabbitMQ una de las librerías que se hizo muy famosa y sacaron de ese código para que otros lo pudiesen aprovechar era una librería que implementaba el protocolo de Raft.

Sí, no tuve la oportunidad de trabajar con eso, pero con Rabbit trabajo todos los días, pero con esa librería en particular no la he tocado. Pero sí he escuchado buenos comentarios de ella.

¿Y cómo ves tú el futuro de Erlang? Porque hay muchos lenguajes que cuando se introducen nuevos lenguajes, nueva competencia dentro de la máquina virtual, que es algo que ya ha pasado a JavaScript, a Java, y ahora está pasando un poco con Erlang, que están surgiendo lenguajes que están tomando popularidad como Elixir, Glimpse. ¿Ves tú que esto está afectando negativamente o positivamente al propio lenguaje de Erlang? ¿Cómo lo ves tú?

Hasta ahora, yo originalmente con esto, cuando surgió Elixir y demás, era bastante escéptico al respecto, pero la verdad que ha hecho, o sea, todo ha sido bastante positivo y algunas cosas han sido extremadamente positivas. O sea, la presión que mete Elixir para mejorar características de Erlang es impresionante, es impresionante. Este, hay varias cosas que tenemos ahora en Erlang que no las tendríamos si no fuera porque alguien dijo Ven que se pueden hacer porque antes de eso era necesitamos una herramienta para formatear código, para darle formato al código y Elixir la trajo en las primeras versiones, o sea no fue la primera versión pero ahí cerquita de las primeras versiones trajo una herramienta para formatear código y en Erlang el consenso había sido no, eso no se puede hacer. Había sido eterno y no se puede hacer. Y la demostración de que sí se podía generó que yo o Mijail Muscala y otra gente dijera, no, bueno, se debe poder hacer, porque si estos muchachos lo hicieron, seguramente lo podemos hacer. Y de hecho ahora hay, existen más de un formateador de Erlang que anda bien, que formatea, que es consistente. O sea, la gracia de que haya otros lenguajes en la comunidad ayuda a que saquemos de encima todos esos prejuicios de no, no se puede hacer, o no, ¿quién va a necesitar eso? ¿Quién va a necesitar una librería que parsee JSON? Y viene ya una década hace que estamos diciendo estaría bueno que existiera una y ahora ya hay. Y lo mismo, Elixir vino cuando salió Phoenix, no sé, los primeros en las primeras versiones antes de la 1.0. Entonces, y con Glimpse pasan cosas también parecidas. Hay herramientas, hay compiladores para distintas cosas, y hay una— Glimpse tiene esa cosa muy de que el código tiene que estar lindo y bueno y entendible y demás, y que ayuda también a mostrar, ven que se puede, ¿no? O sea, se puede hacer este tipo de cosas. Entonces, del mismo modo que se mejora en otros lenguajes, se mejora Erlang.

Está bueno.

Para mí siempre eso viene bien. Y lo otro que tiene es que la comunidad crece. O sea, si antes había gente que no se acercaba a Erlang porque no podía trabajar con Erlang, bueno, por lo menos ahora puede trabajar con Elixir si le gusta, o Glimpse, y luego aprenderemos nosotros de lo que esa persona sabe y aprenderá él de lo que nosotros sabemos. Y es muy sano. O sea, a mí me gusta, me parece muy bueno.

Hace no mucho leí en un artículo que cuando un lenguaje de programación agrega a su librería estándar una librería que en principio no pertenecía al lenguaje en sí, sino que se instalaba como dependencia, era casi como dónde van a morir las librerías. Cada cambio en esa librería pues ya dependía de que los mantenedores del lenguaje en sí quisieran sacar una nueva versión para poder reflejar ese nuevo cambio en la librería. Yo recuerdo que desde el principio Erlang viene con muchas librerías por defecto, una de ellas para XML, pero sin embargo la tendencia no es usar la librería de XML del propio Erlang. Entonces ¿Esto de introducir JSON dentro de la librería estándar de Erlang no se ve un poco similar a ese paso?

Es cierto, pero por otro lado tiene la ventaja de que ahora es oficial. Antes de que existiera la librería de JSON que viene con Erlang, para Erlang existían, por lo menos que yo recuerde, 5 librerías distintas para parsear JSON. Y entonces pasaban cosas como que en cada proyecto se requería un tiempo de decisión para decidir cuál es la librería que vamos a usar para parsear JSON. Ahora ya está, es JSON, no hay nada más que hacer. O lo otro que pasaba es que pasabas de un proyecto a otro y usaban librerías distintas para parsear JSON. Y parsear JSON es algo que generalmente lo hacen las librerías, con lo cual si en tu programa, si en tu sistema incluías 2 o 3 librerías distintas podías tener 4 parsers de JSON. Uno que usabas tú y uno que usaba cada una de las librerías y algunos parseaban una cosa y otros parseaban otra y unos devolvían un formato y otros devolvían otro formato y a veces eran compatibles y a veces no y a veces algunas funciones solo se podían hacer con algunas de las librerías y otras veces con otras entonces sí es cierto que el desarrollo de la librería JSON ahora va a ser más lento pero por otro lado convengamos que es una librería bastante estable, JSON no es un protocolo que está cambiando todo el tiempo y el hecho de que haya una versión oficial y mantenida por el mismo equipo de OTP garantiza que no dependemos de quien sea el autor de las librerías de JSON, que también es cierto que es un problema que tenemos en esta comunidad en particular que es que somos pocos, en otras comunidades por ahí el que mantiene la librería de JSON son 26 personas. Acá en la comunidad de Erlang, para todos los proyectos open source, tienen en un nivel alucinante 3 personas que lo mantienen, digamos. Pero lo general es una y en sus ratos libres, ni siquiera que en la empresa le permiten mantenerlo. Si tienes la suerte, como tuve yo, de trabajar en empresas que específicamente proveían estaba brindado el tiempo para trabajar en proyectos open source específicamente establecido para que uno pudiera hacerlo, maravilloso. Mientras yo trabajé en Nextroll, Hank, Elvis, el formateador y todas las demás herramientas que creamos las mantuvimos maravillosamente. Ahora Nextroll se está moviendo de Erlang a Rust y si te fijas esas librerías están estables, están quietas desde el año pasado, no se ha tocado una línea de código. Entonces, si está en OTP, seguro va a estar al día, y eso es una gran garantía.

Ahí te da, te brinda la posibilidad de que los mantenedores son una empresa que por lo menos destina un dinero fijo a mantenerlo. Y hablando un poco de las empresas, porque ha dicho el tema de que NextRole estaba cambiando a Rust, ¿cómo ves tú el dedicarse únicamente a Erlang?

Y no sucede mucho, la verdad. Creo que hay una discrepancia así en el mercado. Si te fijas en la última encuesta de, creo que es de Stack Overflow o de alguno de esos, los sueldos que se pagan por Erlang son altísimos, pero la cantidad de puestos de Erlang que hay en el mundo es minúscula. Y está asociado a esto de que hay muy poco trabajo para quien recién llega. Si recién empiezas con Erlang, es difícil conseguir un trabajo donde puedas entrar junior de Erlang. Hay sí proyectos grandes, hay proyectos que son el núcleo principal de alguna empresa y esos son enormes, pero generalmente esa gente, esas empresas contratan expertos Erlang, no contratan nuevos. Y tampoco hay mucho nuevo proyecto que yo haya visto, o por lo menos que me hayan contado a mí. Me pasaba mucho más cuando estaba en Erlang Solutions, que sí que aparecían nuevos proyectos de aquí para allá, pero últimamente he visto bastante poco. Y sí que he visto esto que digo, proyectos enormes que claramente necesitan que a quienes contratan entren andando. No tienen el tiempo para entrenar nuevos nuevos recursos. Qué sé yo. En Elixir, por ejemplo, sí que veo que hay algunos proyectos nuevos. Me he enterado de unos cuantos en la conferencia esta que fui a Alemania. Y algunos bastante simpáticos, digamos, con inteligencia artificial, con cosas nuevitas, nuevitas. Pero no estoy en el mercado de Elixir, o sea, a mí no me buscan para trabajar en Elixir, así que no sé.

Entonces ves que entrar a trabajar como junior no es factible para si te quieres dedicar a Erlang.

Entrar a trabajar como junior tienes que encontrar la empresa puntual que justo esté con ganas de entrenar. No es fácil, no es fácil. Trabajo para juniors de Erlang hay poco. Cuando yo trabajaba en Inaca teníamos esa política de que contratábamos gente que tuviera ganas de programar y les enseñábamos Erlang. No necesariamente buscábamos desarrolladores Erlang, pero era una inversión consciente que hacíamos y que no todo el mundo, no todas las empresas hacen, porque encontrar requiere un compromiso del desarrollador. Invertir tiempo en entrenar a un desarrollador para que sea un buen programador Erlang es una inversión que solo vale la pena si si hay un compromiso de parte del desarrollador de luego trabajar para la empresa y no irse a buscar otros rumbos. Y ese compromiso no se encuentra con facilidad. En general, la gente aprende y luego lo agrega a su currículum y pum, se va a buscar otra cosa. Entonces, entonces las empresas no están como muy incentivadas a dedicar tiempo a este tipo de cosas.

Viendo los últimos, yo recuerdo que cuando empezó el boom de WhatsApp, como yo lo llamo, de cuando WhatsApp fue vendido a Facebook, y fue sobre 2014 o un poquito antes, empezaron a salir un montón de empresas que se habían hecho eco de Erlang y querían tener su propio sistema de chat o querían desarrollar todo en Erlang. Y entonces empezó la búsqueda masiva de programadores de Erlang. Y hubo unos años que era un no parar, era increíble la cantidad de recruiters que tocaban al buzón de LinkedIn y llegaban ofertas. La verdad es que últimamente he estado revisando mi buzón de LinkedIn y no sé si será porque me estoy haciendo viejo, pero ya no veo ese movimiento anterior que había de búsqueda de perfiles de Erlang. Y me dio por pensar de que, bueno, tiene que haber algún momento en el que un lenguaje de programación se considera casi como un COBOL.

Exacto.

De que hay mucho desarrollado, de que hay mucho trabajo de mantenimiento, como decía, pero que ya no se busca para hacer proyectos nuevos, sino que solo se busca para mantener, adaptar y evolucionar a nuevas versiones del lenguaje, pero tocando lo menos posible, en caso de que sea posible. ¿Tú habías experimentado más o menos lo mismo?

Tengo una experiencia similar, sí. De hecho, en el boom este de WhatsApp yo trabajaba para una empresa argentina que se dedicaba a reclutar gente y era cualquier persona que haya dicho la palabra Erlang en algún contexto X, lo contactábamos. Si escuchaste que existe un lenguaje que se llama Erlang, te contactamos. Y así, pero no sé qué habrá sido de ellos. Cuando me vine para España los abandoné, pero sí es cierto que no tengo el buzón de LinkedIn tan lleno como solía tener. Por otro lado, pasa lo que ya te digo, que es que las ofertas que sí me llegan son enormes, son ofertas de empresa desesperada porque se le fue el experto Erlang, digamos. Entonces, este, que tiene sentido en lo que tú dices, que necesitan mantener el sistema que ya está hecho.

Se está convirtiendo en un nuevo COBOL en cierta forma.

Sí, creo que por eso digo que creo que con Elixir va mejor. Mismo durante la conferencia encontré varios No son reclutas, son como gente de empresas nuevas que estaban buscando otros para trabajar con ellos, que es algo que solía pasar cuando yo iba a las conferencias en San Francisco con Erlang, digamos, y esta vez aquí en Alemania ha pasado, pero con Elixir. Gente que está buscando desarrolladores Elixir para que se unan a sus proyectos.

En principio ya me he quedado sin preguntas. ¿Se te ocurre algo más que quieras decir? ¿Se te ocurre algo más que quieras añadir?

No, no, estamos bien. Pues como siempre, recomendarle a la gente que se una a la comunidad, que si llegan a Erlang y lo ven complicado, que no desistan. Sí, es un lenguaje muy interesante, muy divertido, que te permite hacer cosas muy poderosas con muy poca inversión en tiempo, en código y demás. Es un lenguaje que código bien escrito dura 100 años, o sea, no es que se te va a morir el sistema porque cambian cosas en la máquina o cambia el compilador o cambia yo qué sé. Código bien escrito dura para siempre acá y que la comunidad es muy abierta, muy receptiva y demás. Así que nada, que participen, que es una cosa muy buena, muy interesante, y que si llegan a ser expertos paga muy bien.

Recomendamos que por lo menos lo prueben, que es un lenguaje muy infravalorado y que merece la pena.

Sí, exactamente. Ah, sí, y que si entran, quieren probarlo, en exercism.io, que es una plataforma de ejercicios con mentoría y demás, si lo quieren probar por ahí pueden ir. Y mi trabajo como parte de, como ser miembro del grupo de educación de la Erlang Ecosystem Foundation es estar presente allí y hago de mentor a todo el mundo que aparezca tratando de escribir código Erlang ahí sin ningún problema y obviamente gratuito, ¿no? O sea, así que si quieren solo para ver qué se siente escribir código pueden probar por ahí que los problemitas son bastante sencillitos y ayudan a que uno pueda enfocarse en escribir código entendible más allá de resolver un problema complicado.

Pues muchas gracias por haberte pasado por aquí, Brujo, habernos dado toda esta información sobre Erlang. Yo creo que es muy valorable. Y si quieres decir algo más para terminar.

No, yo estoy bien. Muchas gracias por invitarme y nada, que lo disfruten.

Bueno, pues este ha sido otro capítulo más de Codeadores. Os esperamos la semana que viene y muchas gracias por haber estado ahí.