El camino a Elixir con Iván Jaimes

Pues buenas otra vez a otro capítulo de Codeadores. Estamos aquí hoy con Iván, Iván James o James.

Es Jaime, sí, Iván Jaime.

Al verlo así escrito me ha recordado la versión inglesa y ya estaba dudando si es que venía del inglés o si era pronunciación española. Entonces estamos aquí con Iván Jaimes, que ha venido a hablarnos un poco de, en principio creo que es Elixir, pero seguramente toquemos otros lenguajes de programación a medida que vayamos hablando. Y para empezar, Iván, yo siempre doy pie a que te puedas presentar y digas algo más sobre qué es lo que haces, si quieres comentar algunos proyectos o algo que haces en el día a día, te presentes. Y digas más o menos qué es lo que haces, pero también que digas ese primer contacto que tuviste con la informática y con la programación. Es decir, ese primer momento en el que te hizo clic y te dijo, causó esa impresión en ti de quiero dedicarme a esto. ¿Cuál fue ese momento específico en tu vida?

Empezamos primero por la presentación. Muchas gracias, Manuel, es un gusto estar contigo y compartir este espacio. La verdad es un honor porque admiro mucho tu trabajo. Por otro lado, pues estoy actualmente desarrollando en Elixir. Me gusta llevar proyectos, tratar de que la gente sea más productiva y enseñarles. O sea, digamos que, ¿en qué me especializo? Pues prácticamente en eso. Ahora, en cuanto a qué fue lo que realmente me inspiró a llegar a desarrollar o a trabajar en tecnología, pues siempre me ha gustado la tecnología. O sea, desde chico, ya sabes, llega cualquier cacharro nuevo y empiezas a trabajar con ese, ¿no? O sea, que si era la, digo, ahí nos vamos a ventilar un poco, ¿no? Y de que empecé con la VHS o la Beta o en todos estos aparatos electrónicos que llevan a casa y a ver cómo funcionaban, cómo se conectaban y por qué era un cable diferente al otro, ¿no? Con el paso del tiempo, pues un poco en la que habrá sido la primaria, que tuvimos acceso a unas computadoras muy, muy sencillas. Eran de la biblioteca de la ciudad. Entonces, en ese entonces yo vivía en el estado de Morelos y había una biblioteca donde podías ir a ver cómo se movía la tortuguita, ¿no? En el Cruce Malego, una cosa así. Y con eso empezabas a jugar un poco en la computadora, me llama la atención. Luego en la secundaria tuve oportunidad de entrar a ver en el salón de cómputo y cómo funcionaba Lotus, que eran los primeros programas que existían, y videojuegos que pues más que otra cosa eran damas chinas, ajedrez y eso, no había mucha variedad porque no los puedes conseguir, pero pues existían ahí y te pones a jugar. Así que de ahí me gustaba mucho eso. En el final, yo creo que el último momento fue en la universidad, cuando ya dices qué tengo que estudiar. Yo quería estudiar algo como mecatrónica, algo orientado a automatizar cosas y todo eso, pero por recursos no pude estudiarlo como yo pensaba. Y también parte mental, o sea, la verdad es que yo creo que si tuviera una orientación diferente hubiera buscado becas y cosas por el estilo para llegar a eso. Así que Eso me parece que es un aprendizaje importante. Y de ahí quise seguir estudiando. Al principio no pensaba en programar, sino en conocer la carrera, de saber cómo funcionaba. O sea, dentro de la carrera yo no usaba Word ni nada porque no tenía computadora, o sea, no sabía ni qué era. Y decían, no, tienen que entregar sus programas en Word y aquí los revisamos. Y yo, ¿y qué es Word? Así que al final con un amigo que estaba en la universidad, me juntaba mucho y preguntamos un poco, y ya me iba enseñando. Así que al final pude aprender un poco más al respecto. Pero sí, definitivamente en ese momento fue cuando empecé a utilizar la computadora y me gustó. O sea, cuando realmente empiezas a aprender sobre lenguajes de programación, pero practicándolos, no la teoría, porque la teoría yo creo que todo el mundo de repente se aburre. Era más como un tema de práctico, ¿no? Y Tuve la suerte de que empezaron a decirme, ¿me ayudas? ¿Me ayudas? Y en ese momento, pues, oportunidades. Si empiezas a vender lo que tienes, digo, si te lo piden y hay oportunidad, pues adelante.

Entonces, la programación la viste en la carrera y a partir de ahí pues ya te lanzaste al mundo laboral y empezaste a programar.

Sí, fíjate que algo muy curioso es que a nosotros nos permitían estar en el laboratorio de computación. Eran 4 laboratorios de cómputo en la universidad. Esta es, este, un área aparte de la facultad. O sea, nosotros teníamos un área que se llamaba CITIS, que era Centro de Investigación de Tecnologías de Información y Sistemas, una cosa así. Y, este, y tenemos la oportunidad de entrar ahí porque apenas lo acaban de inaugurar, entonces necesitaban gente que ayudara a meterle mano. Y ahí vamos de ofrecidos, de voluntarios, y era mucho instalar el sistema operativo, darles mantenimiento, estar viendo las reservas y todo eso. Entonces, en el inter yo quería conocer sobre los sistemas operativos y empecé a instalar diferentes versiones del sistema operativo, de Windows, de Linux. En ese entonces estaba Debian, las primeras versiones, este estaba Mandrake, que luego se convirtió en Mandriva, SUSE, Red Hat, y así varios. En general le pudimos solicitar el Red Hat original por parte de la universidad, y teníamos un UNIX por ahí, un IRIX o algo así, que también estuvimos jugando. Entonces, gracias a eso tuve la oportunidad de dedicarle tiempo a la configuración, a clonar, aprender a resetear Todas estas cositas, ¿no? Y eso creía yo que iba a poder seguir haciendo, o sea, como que era lo que me gustaba, ¿no? Estarle metiendo mano y estar configurando cosas. Y yo dije, me voy a redes, voy a buscar algo. Pero resulta que cuando empecé a preguntar sobre, oye, ¿qué puedo estudiar? O sea, ¿qué puedo especializarme en redes? ¿Cómo lo puedo hacer? ¿No? En los profesores que tenía no tenían esa visión, no nos podrían orientar mucho al respecto. Y de ahí se presentó una oportunidad laboral porque un amigo me recomendó. Me fui a presentar, les gustó cómo resolvimos los primeros problemas. Para ese entonces era Visual Basic, yo creo, ASP, no sé, una versión 5, algo así, una de las viejitas de ASP. Y poco a poco empezamos a aprender sobre eso. Un amigo y yo nos empezamos a a especializar un poco más en todo esto de Microsoft y salió la oportunidad de aprender .NET. Entonces empecé a aprender C# y con C# vino un curso en la misma empresa que nos facilitó el conocer los principios de programación. O sea, no es lo mismo que tú agarres por tu cuenta, te leas el tutorial y te diga ahí, no, Porque lo común es que tengas en los manuales, en los libros, que creo yo es una mala práctica y deberíamos mejorar esa parte, que te ponen la variable, dice tú tienes var a igual a 1, ¿no? Y después puedes usar a y b, ¿no? Y luego lo puedes hacer. Entonces, si en lugar de eso te dijeran qué es lo que estás haciendo realmente con una práctica, por ejemplo, si lo que quieres hacer es una suma, ¿no? Entonces ahí le pones a la función que se llama suma, no nada más mi primera función, por ejemplo. Y también cuando haces un for, no nada más le pones i igual a 0, empiezas y iteras sobre esto, porque como que es la primera barrera con la que me enfrenté y no me sentía cómodo. Y cuando nos enseñan ahí a ser un poquito más, este, pues a seguir las mejores prácticas, a conocer el porqué de las cosas, el porqué se tiene que separar en módulos o en o por qué se tiene que diseñar el sistema de cierta forma para poderle dar mantenimiento a la larga. Yo creo que eso fue muy interesante, aprendimos mucho, y ahí sí aprendí programación orientada a objetos, a diferencia de la universidad, que para nuestra mala suerte los profesores no tenían esa experiencia de utilizar el lenguaje de programación y nada más nos daban lo que estaba en el libro, ¿no? Así que no tienes más que conceptos en tu cabeza de que es un objeto, ese objeto lo instancias de una plantilla, la plantilla es tu clase, la clase le llamas Persona, por ejemplo, y después de eso puedes decir, no, pues este es un estudiante y este es un profesor, y así sucesivamente vas creando tus objetos. Entonces suele ser un poco ambiguo, no es tan claro sobre qué tendrías que hacer al modelar un sistema orientado a objetos y Pues con esto nos abrieron los ojos. En general podemos hacer muchas cositas interesantes y de la mano vinieron cosas como el configurar tu servidor para el despliegue. En ese entonces estamos hablando del 2003, que es cuando empecé, o 2002, algo así, empezamos a programar en esto Pero teníamos que hacerlo manualmente el despliegue, o sea, eran como unas 5 horas que decíamos estos son los pasos, esta es la receta y vamos a empezar. Empezabas a copiar los archivos, a registrar las DLLs, a ver si funcionaba, y cuando ya estaba todo funcionando cambiabas el servidor, o sea, en lugar de apuntar a la IP 1 apuntabas a la IP 2 y ya estaba en producción. Esto era muy manual. Y sí pregunté al respecto. Afortunadamente, las personas que estaban enseñándonos tenían esa capacidad para transmitir la información claramente y entendimos lo que era el despliegue continuo. Todavía no estaba como tal ese nombre, ni tampoco la integración continua, que era el construir tus artefactos en tu computadora local, pero no en tu computadora de desarrollo, sino una computadora en un entorno, digamos, ya más personalizado para hacer eso. Así que al final estas prácticas las fuimos adoptando. Yo personalmente aprendí mucho de eso y cuando tuve la oportunidad de implementarlo en otros proyectos, con el paso del tiempo lo pusimos en empresas interesantes, o sea, grandes, y les gustó mucho. O sea, tuvimos bastante visibilidad como equipo por haber creado este tipo de soluciones. Al final podría decir que nada más estuve yo ahí molestando a todo el mundo para que se hiciera, pero la verdad es que también necesitas de un equipo que te ayude para que funcionen. Entonces creo, creo que eso fue, fueron mis primeros pininos. De ahí llegó un momento en el que yo estaba en una empresa que le estaba dando servicio a la Bolsa Mexicana de Valores. Entonces diseñamos cosas interesantes, estábamos haciendo, pero ya era, para mi punto de vista, ya era un poco aburrido porque es muy burocrático. Tú no puedes crear nuevos servidores ni puedes, o sea, montar nuevos servidores ni decirles vamos a configurarlo para que todo el equipo empiece a desplegarlo, no. O sea, ya tenemos la integración continua, hicimos cosas que pasamos de Subversion, que en ese entonces era lo que se usaba, más bien de, perdón, pasamos de SourceSafe de Microsoft, que era un dolor de cabeza, y lo querían poner con Team Foundation Server. Lo intentamos, pero la gente seguía planchando los cambios, o sea, seguían subiendo cambios que no correspondían a las versiones que nosotros íbamos a liberar. Sino a versiones anteriores. Eran por las malas prácticas que teníamos y porque no había una notificación de que alguien más acababa de subir un cambio. Entonces se sobrescribían y el build fallaba y no sabías por qué. Y decían, es que fue el último el tuyo. No, que fue el mío. Entonces eso generó un problema. A raíz de eso, lo que hice fue migrar de Team Foundation y puse un servidor con Subversion. Y con esto lo que intentaba hacer era demostrarlo. No quería reemplazar toda la arquitectura, nada de eso. Solamente lo que quería era validar que realmente era eso, que ese era el problema. Con el paso del tiempo la gente se fue uniendo, lo pusieron, lo empezaron a usar más, y había un iconito que se registraba en tu, ¿cómo se llama?, en tu tarea, en tu barra de tareas de Windows, con un sistema que se llamaba CrashControl. No sé si todavía exista el CrashControl.net, pero era lo que actualmente podemos conocer como, como este servicio de integración continua, te proveía de eso. Entonces ahí lo registrabas, se hacían los builds, y cuando pasaba el build y las pruebas unitarias, que también no era muy común que la gente usara pruebas unitarias, te mandaba la notificación a tu barra y sabías tú que alguien había desplegado. Entonces eso hizo un cambio completamente de juego, les gustó mucho. Pero a pesar de tener todas estas cosas que en ese momento eran como una especie de innovación, la gente no lo adoptaba fácilmente en otros lugares. O sea, eso era un proyecto, era el proyecto que estaba en ese momento trabajando, pero para otra área de la misma empresa no lo querían adoptar y costaba mucho trabajo el convencerlos. Así que eso fue un poco cansado y era mucho problema interno, así que opté por conocer otras tecnologías y entre esas apareció Ruby primero. De la mano de Rubí aprendí mucho porque no teníamos en ese entonces en Microsoft un, bueno, en la suite que yo conocía de Microsoft, a lo mejor dentro de Microsoft sí lo llevaban, pero en lo que yo estaba como consultor no tenían las migraciones y todo lo hacíamos como versionados por archivos de SQL. Y según esto habían soluciones que se estaban dando para SQL Server en las cuales te instalabas un plugin, te permitía ser versionado y todo, pero no era nada simple. Entonces lo más bonito que encontré fueron las migraciones con Ruby. Dije, wow, esto es diferente. Aquí puedo hacer migraciones, lo cambio, me regresa una versión antes, una versión después, y encuentro la versión que yo quiero de la base de datos. Además de eso, el poder hacer el llenado de la información en otro paso también era muy bonito. El hecho de que no se casara todo con orientación a objetos también era bonito porque podías ejecutar scripts muy sutilmente en la consola y todo. O sea, como que No había encontrado un problema en eso hasta que tuve que lidiar con varias versiones de varios paquetes. Ahí fue donde empezó el dolor de cabeza un poco en Ruby, porque pues los manejadores y todo eso era diferente. Pero aún así era mucho más soportable que el hecho de que no tuvieras una herramienta agradable en Microsoft como para poder desplegar en su momento con las herramientas de .NET, porque generalmente aunque tenías plugins que se adaptan, no funcionaban para todos. Entonces tenías que seguir ciertos pasos, había problemas de escritura, de permisos, tenías que volver a crear un usuario, o sea, un montón de cosas para poder llegar a automatizar el despliegue para ese entonces. De ahí que había buscado otras alternativas, y en otros proyectos que estuve con otras empresas surgió la oportunidad de aprender Business Intelligence, que también es una suite de Microsoft donde tenemos Integration Services, Analysis Services, todas estas cosas para explotar los datos, la minería de datos, en donde trabajabas con cubos y reporting services y cosas por el estilo que son bastante útiles y que en ese entonces requerían cierto estudio diferente a lo que hoy conocemos. Como que eran las bases, que al final todavía lo puedes hacer y te ahorras mucho dinero en infraestructura, pero requieren de mucha mucho análisis, diseño y una creación disciplinada de todo tu desarrollo. Entonces sí, definitivamente es un cambio importante, pero me sirvió para conocer más el tema de bases de datos. A partir de esto tuve que lidiar con otras bases de datos como son Postgres, MySQL, Oracle, y eso me abrió los ojos. O sea, como que dije, no es solamente programar en la parte del front, no, hay que hacer más cosas atrás, y tiene su razón de ser. O sea, llega el momento en el que existe el NoSQL, empieza a ser el boom en NoSQL para ese entonces. Y aún así yo seguía teniendo la duda, ¿por qué? ¿Por qué me pides hacerlo con NoSQL si al final al NoSQL le vas a poner índices, le vas a poner relaciones, le vas a poner constraints en tus esquemas? No sé, se me hizo un fix ahí medio raro, aunque tiene sentido para muchas otras soluciones. O sea, el hecho de que puedas cargar datos masivamente ahí sin que tengas ese constraint, esos índices, obviamente aceleras en la inserción de datos y en algún momento los puedes procesar de una manera diferente y los tienes igual muy rápido. Depende de cómo lo gestiones y cómo diseñes todo tu sistema. Entonces, todos esos detalles me fueron dando una visión un poquito más amplia sobre cómo diseñar sistemas. Todavía me sentía en pañales, definitivamente. Cada vez que cambiaba de tecnología sentía que no podía hacer nada, o sea, que necesitaba estudiar más. Y después llegó el momento de utilizar Go. Un amigo me dijo, sabes qué, acaba de salir Go. Y le digo, ¿y qué es eso? Y me pasa la liga y todo. Y le dice, ¿qué crees? Estamos en una startup, lo estamos usando. Y yo, ¿a poco? O sea, ya lo están usando, no hubo problemas, no tuvieron esa barrera. Se me hizo muy raro que no tuvieran esa barrera. Me dijo, sí, y estamos contratando a un desarrollador en backend, ¿quieres unirte? Yo dije, pues va, ¿de cuánto tiempo tengo? Y me dijo esto el lunes, me dice, pues el siguiente lunes puedes venir a presentarte a la entrevista. Así que tuve una semana para estudiarlo y aprenderme las bases, así que cuando llegué ahí pude resolverlo. Porque la verdad es que era muy sencillo, a diferencia de las, de las soluciones que tenías con .NET, con C#, en donde tienes que instalar todo, son como 8 GB, 15 GB, tienes que darle siguiente, siguiente, siguiente, y luego después de eso ves que una vez que lo corres te falta algo y lo vuelves a dar siguiente, siguiente, te falta algo, siguiente, siguiente, y luego eran permisos, y bueno, ya terminas, o sea te tardabas todo un día en poder instalar tus herramientas y al día siguiente para instalar el proyecto tampoco era como que muy agradable porque resulta que te faltaba algo. Entre esos temas que no venían, o sea, no estamos acostumbrados a hacer documentación, entonces te saltabas algo. Con el cambio que hicimos a Go, cuando yo lo vi, decía ahí nada más en el README dice bajas el Dartball, pones estas rutas, esto en tu bash, y ahí lo debes de hacer. La convención es que tú tengas un GOPAT y en ese GOPAT tengas los datos que vas a usar. Listo, se acabó, binarios, no hay problema. Yo dije, no puede ser tan fácil. Pues sí, lo puse y funcionó, y empecé a trabajar en la consola, y me gustaba trabajar en la consola, así que fácilmente le entendí. Ahí empecé a conocer editores como Vim, porque a pesar de que ya escuchaba, ya lo había, o sea, los había trabajado desde la universidad para los servidores, porque entras con Nano y no es a nivel de desarrollo. Porque cuando trabajas con Visual Studio en ese momento, que era de esas herramientas muy visuales, o sea, que tenías que instalarlo en el escritorio y el IntelliSense y todo eso se tardaba muchísimo, requería, tenías muchos recursos. No es como el Visual Studio de hoy, que es mucho más ligero, tiene plugins y extensiones y está bien pensado. En ese momento era súper lento, así que cuando me dijeron no, pues agarra cualquier editor. Traté de utilizar Notepad++, no era tan agradable. Me pasé a Vim, medio funcionó, tenías extensiones y todo. Conocí NeoVim y otras cositas interesantes. Y luego empezamos a desarrollar ahí con como que muchas cosas que yo había tenido ganas de aprender, que es el tema de seguridad para hacer el login, que es el tema de seguridad para autenticarte con Google, con el OAuth, a usar protocolos, tratar de enviar la información comprimida, montar el servidor desde cero. No existía Docker como lo conocemos ahora, sino estaba en pañales, y tratábamos de utilizar Docker. Todavía no funcionaba muy bien, teníamos fallas, y de repente se presenta Elixir, ¿no? Ahí llega justamente la persona que nos dio el curso de .NET ya se había metido en Elixir, porque no sé de qué suerte conocía a José Balín en temas de Ruby y todo eso, y nos dijo, mira, esto parece estar interesante, vamos a dar un curso aquí en México dentro de poco, así que si te apuntas pues eres bienvenido. Yo dije, pues de aquí soy, no, vamos a ver, hay que, es el momento de conocer más cosas. Como ya me sentía lo suficientemente tonto para aprender cosas, dije, aquí me tengo que aprender algo nuevo sí o sí para dejar de sentirme así, que no puedo avanzar, ¿no? Porque llega un momento en el que aunque tienes conocimiento de arquitectura, de diseño, de las herramientas, de todo, si no estás en la misma tecnología que con la que iniciaste, no tienes esa seguridad de que vas a poderlo aplicar. Muchas veces lo intenté, pasar de C#, por ejemplo, a Go orientado a objetos, y me topé con que era un problema mayor. O sea, había dedicado mucho tiempo a pensar una solución como si lo hubiera hecho en C#, que es un error garrafal, porque al final tienes que aprender cómo está pensado, porque tiene otra solución en mente, ¿no? Quien creó el lenguaje y tiene un problema particular que quisiera resolver. Así que eso me ayudó mucho. Y cuando empecé a estudiar Elixir, yo tenía ahora la idea de Go, como que era diferente, era funcional y todo, sí, pero aún así traía yo cierto legado de orientado a objetos. Con Elixir fue completamente diferente, ahí cambió el paradigma y cambió lo principal que para mí fue la inmutabilidad. Hasta cierto punto, el que un objeto pudieras pasarlo en una función era muy fácil, era muy agradable, porque nada más pasabas un parámetro y ya lo usabas adentro. Pero hay un detalle: como pasa por referencia, actualizas el objeto, y entonces cuando sale de la función tú no te das cuenta, pero ya afectó algo. Y son errores de lógica que en algún momento te afectan en tu desarrollo. Y que conllevan a otros problemas que por diseño, sí, no puedes solventar fácilmente. Y son temas que fueron sucediendo en este, en ese momento, que me hicieron estudiar un poco más al respecto, que nos, que hacen que aprendas como de la manera difícil, ¿no? El porqué en el libro te dicen que este es el deber ser de las cosas. O sea, una cosa es que te lo digan, pero no te lo quedas grabado hasta que no te pasa a ti. Y de ahí es que me gustó mucho. También utilicé otros lenguajes de programación como PHP en su momento, y me parecía un poquito sucio, no sé, sucio en el sentido de que es difícil de leer a veces, a veces es muy sencillo de crear, Igual con Perl, como que tienen esa sensación de que haces las cosas muy rápido y ya lo tienes, pero cuando regresas a él como que otra vez tienes que agarrar la idea. Está acostumbrado desde C# a escribir la documentación y a verlo fácilmente, o a colapsar las regiones, colapsar el código y verlo sin que me cueste trabajo la lectura. Cuando paso a otros lenguajes no es lo mismo y cuesta un cierto trabajo. Entonces el que tú puedas trabajar con Ruby, donde es un poquito más legible, la sintaxis es más agradable, sentía yo que era más productivo. Cuando llego a Elixir, Elixir definitivamente para mí fue algo completamente diferente. Al principio era un dolor de cabeza porque el hecho de que tú no tuvieras que regresar nada en una función, o sea, no necesitas explícitamente decirle un return algo, sino nada más poner una expresión y el resultado de esa expresión es el que se va a regresar. Eso, eso no lo había identificado y por mucho tiempo me generó errores uno tras otro, porque yo le ponía al final la variable o quería regresar algo cuando eso no era lo que esperaba. Este, también el tema era crear funciones que te devolvieran una sola cosa muy sencilla. Algo, hay un patrón que me gusta mucho que es el manejo de errores. Con el éxito, que tú le regreses una tupla, es un OK y el valor, ¿no? O sea, quiere decir se procesó correctamente lo que tenía que hacer esa función y te regreso el valor que debe regresar esa función, o los valores. Y por el otro lado, si hubo un error, te notifico, sabes que hubo un error en esa tupla, te lo digo, y te digo el resultado del por qué hubo ese error, ¿no? Y si necesitas algún otro objeto, bueno, no objeto, algún otro elemento que regresar para continuar con tu operación, pues también lo regresas. No es nada complicado y es muy legible, a diferencia de Java o C#, que cuando tú regresabas un valor, tú esperabas que, o sea, para ti es funcionó, es lo que yo espero. Y si tengo un error, es una excepción, pero esa excepción puede burbujear, o sea, puede salirse de una función, de otra función, de otra función, y al final llega hasta arriba y no supiste ni qué era la excepción. Ni de dónde proviene, y tienes que leer todo el stack trace para saber qué es lo que pasó, ¿no? Entonces alenta mucho tu desarrollo y es complicado manejar lo que realmente son errores y no excepciones. Así que con Elixir dije, es otra cosa, que ya en Go lo tenía hasta cierto punto manejado, porque Go te permite regresar por convención, ¿no? Te valida si el error tiene algún O sea, si la variable error regresa algún elemento, entonces hubo un error y lo manejas. Pero también puedes tener un panic en algún momento porque, no sé, hiciste algo mal, diseñaste algo mal y te va el panic, pero ahí se cae tu aplicación. Lo puedes capturar a un nivel global y todo, pero nuevamente tienes que inicializar todas tus variables o inicializar todos los elementos que iban a estar trabajando para ese momento. Como por ejemplo en el tema de servidores, cuando estás dando el contexto en Go, lo tienes que estar asignando, lo vas pasando, pero es mutable. Esto quiere decir que se puede cambiar en cualquier momento el valor de ese contexto y no es como una copia, sino más bien es ese valor que tú tenías en un principio y lo estás reemplazando, y en algún momento te genera un problema. Porque no sabes si realmente es lo que estaba llegando desde un principio o lo cambiaste en el camino. Lo que me gusta mucho de Elixir es que con los blocks tú le puedes pasar la conexión, llega el objeto conexión, lo vas modificando internamente, pero lo estás alterando. Hay una inmutabilidad, o sea, no hay una referencia, sino que se crea un nuevo elemento, se le asignan los nuevos valores, y ese es el que se pasa de regreso. Entonces tampoco necesitas un garbage collector. Porque el garbage collector prácticamente no es necesario, no a ese nivel como lo conocemos, de que tiene que estarse deshaciendo de la memoria que no usa, porque prácticamente en el momento en el que ya no estás utilizando esos valores se pierden y creas un nuevo valor, y esos son los que sigues utilizando. Entonces es súper eficiente. Y bueno, al final, este, ya me he seguido platicando de todo esto, podríamos seguir ahí otro rato, pero no sé si tengas otra pregunta antes de continuar con todo esto.

No, bueno, creo que ha ido enlazando bastante bien. Las preguntas que yo suelo hacer van en base a los lenguajes de programación que has tocado. Como bien has dicho, ha ido tocando primero C#, ASP, pasaste a Ruby, de Ruby a Go, lo cual es un cambio bastante extraño. La mayoría de gente que conozco siempre pasa de Ruby directamente a Elixir. Tú, sin embargo, diste un pequeño rodeo y cambiaste a otro lenguaje diferente, lo cual está muy bien también porque Go tiene bastante similitud en la parte de concurrencia con Erlang y Elixir. Y yo creo que eso te puede, te puede haber dado una idea de por dónde iba la parte de concurrencia en Elixir y cómo manejarla, para que esa dificultad que decías que habías encontrado inicialmente no fuese tan grande. Pero al hilo de esta conversación, porque como han mencionado tantos lenguajes y son bastante diferentes, ¿con qué te quedarías de cada uno de esos lenguajes? ¿Qué impresión te da cada uno y para qué utilizarías cada uno en base a, pues mira, por ejemplo, Ruby por su facilidad de scripting y demás sería mi lenguaje de elección para hacer Scripting únicamente, o incluso Perl u otro lenguaje, y Elixir para proyectos grandes, o Go para proyectos grandes. O sea, ¿cuál sería tu elección para esos proyectos? O incluso, ¿qué amoldarías de uno y otro para según qué caso?

Claro, pues mira, definitivamente algo que me gusta mucho de Elixir es que es el resultado de toda la experiencia que tienes con otros lenguajes. O sea que si tú te das cuenta de dónde toman cada cosa el lenguaje, puedes como que saber hacia dónde tirar en algún momento. Un ejemplo es, si tú quieres transmitir fácilmente el uso de una API, yo optaría por poner un ejemplo en Ruby, aunque no sea como tal. ¿Por qué? Porque Ruby es claro en lo que estás haciendo y te facilita. Pero si quisieras orientarlo a que te den un ejemplo y que puedas ejecutarlo en cualquier lado, utilizaría Bash, o sea, porque la intención es probar el API, no es que te dé los datos, y no lo vas a desarrollar, sino nada más copias, pegas y te da la información. Entonces lo usaría mucho para eso. Si tú quisieras leer, por ejemplo, un servicio que está con WSDL, no, que es la especificación anterior de los servicios para comunicar entre sistemas, utilizaría .NET porque .NET ya tiene un asistente en donde le das siguiente, siguiente y te descarga todo eso. Si tú lo creas con otro lenguaje como Go, por ejemplo, te va a tardar mucho tiempo porque tienes que leerte la especificación y hacer esa capa, o aunque tengas una biblioteca para poder trabajar con eso, es más lento. Entonces, en ese sentido, rescataría mucho esta facilidad de las herramientas de Microsoft para poder interactuar con este tipo de cosas. Por ejemplo, para trabajar con generadores de código, o sea, para crear, no sé, más código, tal vez para generar plantillas, o para generar donde tengas muchos elementos que repetir, podría utilizar hasta las plantillas de Microsoft, porque hay un, con C#, tú puedes agarrar un template, un TXT, y le pones los datos y luego lo vas reemplazando rápidamente, y tiene su asistente. O sea que prácticamente en menos tiempo puedes hacer más. Pero si se trata ya como de un desarrollo puntual, como un sistema para generar el boilerplate o todo esto que necesitas de inicio, utilizaría Elixir porque Elixir te facilita las cosas con el mix y las tareas, porque te permite generar plantillas de la misma manera, pero tienes un sistema de validación pruebas unitarias que nacen con el mismo lenguaje, que ya te facilitan estas herramientas. Entonces, tratando de responder mejor la pregunta que me hiciste sobre qué rescataría de cada, de cada lenguaje, de todo el ecosistema de .NET, creo yo que el tema de experiencia de desarrollo, o sea, con la facilidad que te brinda, el querer brindarte la las herramientas lo más fácil posible. Yo creo que eso es lo más importante, que el desarrollador pueda hacer las cosas fácilmente. No por eso quiere decir que sea la mejor herramienta, pero eso es lo que me quedo de ahí. O sea, el tener una agradable experiencia de desarrollo es lo que yo pondría en un lenguaje de programación. Eso es bonito. En cuanto a Ruby, me gusta que es expresivo, es fácil de leer, es claro. Entonces tú puedes pasarle el código a alguien más con menos documentación y lo va a entender fácilmente. Eso me gusta de un lenguaje de programación y me gustan esas partes de Go. Go yo creo que es como un tema de bajo nivel, es bonito trabajar con él, es como de, es para entretenerte, no, es hacer herramientas de líneas de comandos o de integración o de despliegues, por ejemplo, porque tiene APIs que te facilitan el el trabajo y herramientas, me gusta para eso. No siempre lo usaría, pero tiene una buena ayuda. Con respecto a Python, por ejemplo, Python me gusta para hacer cosas rápidas, o sea, en donde no tengas que preocuparte por el performance, sino más bien te preocupas por la facilidad con que haces las cosas. Entonces quieres descargar un vídeo de YouTube, por ejemplo, agarras 2, 3 cosillas, utiliza una biblioteca, lo registras y bajas. Y empieza a bajar las cosas, a utilizar el encoding, bla, bla, bla. O sea, en muy poco tiempo puedes tener un resultado claro, pero no es para todo. O sea, yo no usaría Python para un sistema en la web y que te dé por el resultado, o en Ruby, porque la escalabilidad llega a un momento. De hecho, a raíz de esto surgió Elixir, ¿no? Como muchos saben, la historia proviene de Valim, que Valim estaba trabajando justamente en el core de de Ruby y aportaba a las bibliotecas y tenía un montón de colaboración ahí. Y resulta que con su empresa, que era Plataforma Tech, trataba de resolver un problema que no se presentaba continuamente, sino que no había forma de replicarlo fácilmente porque estaba orientado a cómo lo habían montado en un hardware, y ese hardware no estaba optimizándose, sino sencillamente estaba estaba generando problemas aleatoriamente porque se peleaban los recursos, había race conditions y todo esto. Y al final trató de resolverlo y encontró que ya había un lenguaje que lo estaba haciendo, que era Erlang. Y gracias a su eficiencia, a todo este tiempo que se dedicó para poder resolver ese problema, él podía utilizarlo y crear un lenguaje encima de él. Porque ya existían otros lenguajes que corrían sobre la máquina de Beam. Entonces estaba, estaba genial, o sea, es una solución perfecta para eso. Y de ahí es que me gusta mucho como para hacer este tipo de sistemas donde quieres hacer sistemas robustos, donde realmente quieres ofrecer alta disponibilidad, o sea, que no quieras tú estar metiéndole Dockers a granel y así, y estar levantando máquinas para cuando tengas un Black Friday y de repente aún así se te van a caer y los despliegues no van a quedar, y de todos modos vas a tener problemas porque pues tu equipo no, no va a solventar todos los issues al mismo tiempo, ¿no? Sin embargo, con Elixir, y hay muchas pruebas que lo demuestran, este, creo que por ahí en uno de tus libros mencionas algo de eso, ahorita, ahorita que lo recuerdo, que justamente es cómo se solventan ese tipo de problemas y el porqué, ¿no? Si nos vamos a esto, este, pues bueno, creo yo que ya he visto, ya he dado un poquito de de la respuesta de cada cosa. No sé si me haya faltado algo.

No, no, quedó bien. Y te quería preguntar también, porque ya has dicho que hacías cosas con Python y Ruby, y te iba a comentar de forma un poco malévola, porque sabes que siempre hay lenguajes de programación que están enfrentados con otros, ¿no? Por ejemplo, en el caso de C#, Hay gente que utiliza C# pero no le gusta Java, y gente que utiliza Java pero no le gusta C#, cuando los dos son bastante parecidos, completan una misión bastante similar y podrían utilizarse de forma intercambiada. Y tal y como dices, ambos tienen muy buenas herramientas, tienen un rico ecosistema de un montón de empresas que han ido proporcionando editores y todo tipo de herramientas empresariales. Y en el caso de Ruby on Rails, yo siempre he tenido como su competidor Python y Django, que era casi como las dos opciones que teníamos cuando utilizábamos uno u otro. En el caso de Go, creo que podría ser uno de sus competidores Rust, por la fecha en la que surgieron y cómo se utilizan uno y otro, pero ahí no lo tengo del todo claro. ¿Cómo ves tú estas competencias y que se utilicen uno u otro, o que incluso la gente se ponga como se pone cuando utiliza uno y pelea contra otro?

Fíjate que eso está interesante, es muy buena pregunta. Este, yo veo, de hecho viví esa parte en la que tú como desarrollador todavía estás defendiendo C#. Porque había otros que trabajaban con Java, me decían métete a Java, mira, velo y vas a ver las diferencias y todo. Evidentemente Java era más viejo para ese entonces y tenía más soluciones probadas y estaba claro que tenía una cierta ventaja al respecto, pero por el otro lado tienes a Microsoft que agarró, si tú lo quieres ver, Java, le puso unos cuantos millones en la licuadora, los agita y tienes un resultado interesante. Para hacer algo similar. Creo que ambos son como un tema de marketing, porque tienes dos empresas grandes que están peleando. Es como cuando ponen los anuncios de la Mac y Windows. Al final, ninguno de los dos, a los dos les da igual, porque el hecho de que pongas esos anuncios es solamente para divertirse, porque cada uno tiene su mercado y va a seguir teniendo su mercado. Así que yo más bien digo como desarrolladores debemos de aprender más de un lenguaje. O sea, hay que fomentar el uso de otros lenguajes porque te abre la mente. Es como viajar, o sea, tú no sabes lo que es hasta que no lo haces, y entonces es cuando entiendes que sí te abre la mente. Tienes otras soluciones, otra manera de pensar, tienes otras herramientas, y aprendes de lo que es bueno y lo que es malo en cada lenguaje. Prácticamente, por ejemplo, lo que era Java en su momento Cuando llega C#, a mí me tocó ver que en Java fue un parche las pruebas unitarias, y C# se supone que ya venía con todo, y también tuvo que hacer el parche y meter pruebas unitarias después. O sea, no venía pensado en eso, o sea, no lo tenían. Eso qué quiere decir, que al final no habían resuelto los mismos, no habían resuelto los problemas que tenían, que realmente no era el ofrecer que corriera sobre cualquier plataforma, sino el brindarle herramientas al desarrollador para poder hacerlo bien, que en ese momento era como que más valioso porque ya lo demás ya lo teníamos. Entonces, después, al ver, por ejemplo, cuando nace Go, Go ya nace con ese tipo de cosas, ya nace con las pruebas unitarias en la biblioteca estándar, igual Elixir. Y esos son aprendizajes como tal de los mismos desarrolladores o de los creadores del lenguaje. Y eso es algo que me gusta mucho, o sea, es un ejemplo claro de por qué debemos de estudiarlo, ¿no? O sea, a mí me parece un excelente ejemplo el caso de José Balín de haber aprovechado sus estudios y haberlo encaminado a lo que realmente tenía sentido para él, ¿no? El haber estudiado y haber seguido en la misma línea. O sea, tú estabas estudiando lenguajes de programación, te vas a la maestría, sigues estudiando, ¿no? Y vas metiéndolo como parte de eso, la creación de que está basado en lo que a ti te gusta. Y al final aportas algo a la comunidad, y ahí tiene mucho más valor porque realmente conoces del tema, te informas y tienes más herramientas para poder trabajarlo. Así que al final el tema de que estén peleándose entre un lenguaje y otro de programación se me hace un poco cerrado, como que es, es el resultado o la consecuencia de nuestra propia ignorancia. Y a su vez es divertido porque te ayuda a encontrar esos pequeños defectos entre un lenguaje y otro y te ayuda a mejorarlo. Así que tampoco está tan mal.

Y más allá que tú mismo lo comentaste hace un momento, de que al cambiar de un lenguaje a otro, por ejemplo, el cambio de C# para Go, O incluso el cambio de Go a Elixir, que te tocó cambiar un poco el cómo plantear los problemas para llegar a esas soluciones, a la nueva forma de hacer la solución en esos lenguajes. Cuando tienes que encarar el aprendizaje de un lenguaje que en principio puede parecer similar pero que es tan diferente, ¿Cómo encaras tú ese aprendizaje de ese nuevo lenguaje para decir en poco tiempo? En este caso has puesto el ejemplo de que con Go lo tuviste que hacer en una semana. ¿Cómo consigues tomar los fundamentos o entrar en ese lenguaje y que sea fácil el aprendizaje?

Realmente yo no creo haber aprendido en una semana, más bien lo pude ejecutar, lo pude echar a andar y pude demostrar que puedo usarlo. Yo creo que ese fue el resultado en una semana. Dominarlo tampoco lo creo, porque al final no le dediqué tanto tiempo como yo quisiera. Fueron nada más 2 años y yo creo que dedicarle tiempo para especializarte en un lenguaje requiere mucho, o sea, requiere no solamente ese tiempo de estar programando, sino requiere el estarlo estudiando, sí, el porqué de las cosas, encontrar la raíz y la razón de las cosas. No creo tener una receta para esto, pero una forma en la que yo lo he abordado y que me ha resultado mejor que las otras que había abordado previamente es, primero que nada, leer al respecto, o sea, el origen del porqué surge ese elemento lenguaje. Un ejemplo más claro lo tienes con justamente Go. Go, el origen para poderlo, del por qué salió, es porque lo tenían todo en C en Google, estaban trabajando y la compilación tardaba mucho. Entonces se enfocaron a hacerlo más eficiente al momento de compilar y se orientaron también a crear un lenguaje que fuera muy similar a lo que ya conocía el desarrollador para que pudiera adaptarlo, adoptarlo fácilmente. Entonces creo que de ahí viene la facilidad en la que puedes tú adoptar la sintaxis de Go porque te hacen ligeros cambios, o sea, sigues teniendo una igualación pero además de eso le puedes poner dos puntos e igual para evitarte el var o la declaración del var. Entonces detalles como esos son interesantes, o el hecho de que cuando le pasas los parámetros a una función, si en lugar de ponerle el tipo de dato le pones coma y al final le pones el tipo de dato, haces ver que todos esos elementos, sus parámetros anteriores, van a ser de ese tipo, ya sea entero, string, o lo que sea. Es como esos pequeños detalles, no los vas a aprender fácilmente hasta que no veas mucho código. Entonces vale la pena que inicialmente sepas el origen, luego después puedas darle un overview. Una de las cosas que yo bajo es una chuleta, o sea, la sintaxis, la estructura estructura de cómo debes de crear el código para poder, este, generar rápidamente bloques, como por ejemplo de un for, de un ciclo, de un while, ¿no? En Elixir puedes utilizar los enums, las iteraciones, los reduce, etcétera, etcétera. Y ya con eso te ahorras mucho porque ya prácticamente conoces lo que hace internamente, o sea, ya sabes que puedes hacerlo y lo único que te hace falta es la sintaxis, ¿no? Porque ya tienes esos principios. Si tú ya tienes el principio, es muy fácil reemplazarlo por la sintaxis, o sea, ya no necesitas tanto. Sin embargo, esa es la primera fase, es nada más para poder crear. Todavía te hace falta el poder transmitir tu conocimiento y el dejar un proyecto y pasárselo a alguien, que ese es el que tiene más valor, porque tú puedes duplicar tu productividad o triplicarla cuando facilitas que otras personas hagan su trabajo. Entonces, para que se lo facilites, necesitas aprender las convenciones de cada lenguaje. Por ejemplo, en Go la convención es diferente a la convención en Ruby, ¿no? O sea, el que tú en cierto momento tengas un nombrado camelCase o PascalCase o lo que tú quieras es diferente. Y si lo pasas, por ejemplo, en JavaScript con TypeScript, también una cosa que estás que tenemos muchos problemas, o yo me he enfrentado con esos problemas a la hora de crear el front, es que las convenciones son tan flexibles y tan variables que cuando tú quieres entender el código y ves un proyecto muy grande dices, bueno, ¿y entonces cómo lo tengo que hacer? No, no, es que ya mandas el pull request y te dicen, es que eso no era así, mira, es que eso ya lo estamos haciendo con Flow, no sé qué. Aunque te pones a hacerlo y de repente, no, pero ya cambiamos a la nueva versión, ahora vamos a hacerlo con TypeScript. Dices, carajo, o sea, decídete. No, no puedo transmitir el conocimiento fácilmente, que es algo que hizo muy bien Next.js cuando puso las convenciones, puso las reglas y dijo, en este framework se hace de esta manera, y si quieres lo usas y si no te vas a otro lado, ¿no? O sea, eso yo creo que tiene mucho valor. Y cuando tú adoptas eso en un lenguaje de programación, ya tienes una gran parte ganada porque fácilmente puedes transferir tu código y van a ser más productivos como equipo.

La verdad que hay muchos lenguajes que tienen lo de convención sobre configuración. Yo creo que, no estoy muy seguro, pero apostaría que Ruby on Rails fue uno de los primeros frameworks que lo implementó. Y al hilo de esto, porque después de trabajar en varios entornos completamente diferentes ¿Cómo ves tú la salida laboral para ese tipo de entornos? Es decir, ¿crees que es más valorable saber mucho aunque no te especialices en nada, o es mejor especializarse en algo y centrarse solo en una de las cosas?

Pues yo creo que definitivamente especializarte te ayuda. O sea, te ayuda porque estás en una burbuja en la cual te conocen, en la cual recurren a ti, y como que después de un tiempo siempre van a recurrir a ti, ¿no? A mí me pasó que cuando cambié de .NET a otra tecnología me siguen buscando por .NET y yo ya no quería hacer eso, pero los que yo buscaba, que eran las nuevas tecnologías, tenían que empezar de nuevo, entonces me costaba trabajo encontrarlo. La ventaja que tuve fue que conocía a gente, me llevaba bien con ellos, y al final tuve oportunidad gracias a eso, ¿no? Pero si me dices a qué le dedicaría más tiempo, pues le dedicaría más tiempo a relacionarme bien con la gente y a aprender de la gente, ¿no? No tanto al lenguaje en sí. Y especializarme sí vale la pena, yo creo que es algo que tiene mucho valor porque el que mucho abarca poco aprieta. Pero por otro lado, creo que también el hecho de haber aprendido de diferentes lenguajes, sin darme cuenta, también me especialicé en algo, ¿no? Que fue el trabajo en equipo. Entonces, al final, no lo veo como que haya sido una pérdida de tiempo, ni tampoco como algo desgastante, pero sí lo veo como algo más de valor que tengo que aprender, ¿no? Aprender a subsanar ese tipo de detalles, esas desventajas que el hecho de no haberme especializado en una tecnología, con el tiempo que llevo, este, pues obviamente tengo que subsanarlo de otra manera. Por otro lado, a nivel de lo que mencionas laboral, ayuda mucho que estés especializado porque la gente te conoce, o sea, tienes un reconocimiento. Tengo amigos que siguen en .NET, ya están en Microsoft, son parte de plantillas directivas y todo eso, y les va muy bien. O sea, lograron hacer una carrera interesante ahí. También de los otros lados, por otro lado, no, hay gente que trabaja en PHP todavía, es muy bueno y sigue con un empleo muy, muy bien remunerado y estable porque al final son buenos en lo que hacen. Como bien dices, a veces no, no hay ese espacio en la plantilla laboral, no, o sea, como que si te quieres cambiar de una empresa a otra, por ejemplo, lo que mencionabas en otro podcast con Erland, Puede que cueste trabajo, sí, pero al final tienes trabajo, ¿no? O sea, sí te puede llevar tiempo y todo, pero es un hecho de que mientras seas bueno vas a tener ese, ese trabajo. Así que no sé, depende de lo que te guste, qué quieras armar, ¿no? Qué quieras hacer, hacia dónde te quieras dirigir, porque también las habilidades blandas, ¿no? Son muy útiles y definitivamente suelen ser mucho más gratificantes cuando las sabes desarrollar.

Y sobre, como a ti creo que te pasa como a mí, de que vas aprendiendo tecnologías nuevas cada poco tiempo e intentas sacarle partido y empezar a trabajar con ellas directamente. Ahora está en una etapa en la que estás trabajando principalmente con Elixir. ¿Ves que tu futuro está de momento ahí por mucho tiempo o ya estás empezando a echarle ojo a otra tecnología nueva?

No, fíjate que desde hace tiempo, digo, tengo, pues empecé por el 2014 con Elixir, pero de oídas, o sea, no lo desarrollé, nada más lo escuchaba, escuchaba cómo lo iban haciendo y todo, y leía los, o sea, realmente no lo trabajé hasta Después habrá sido como 2016, 2017, y de ahí lo he usado más seguido, más seguido, poco a poco. Así que definitivamente me gustaría seguir en esa tecnología, aunque no siga desarrollando en algún momento, porque a veces como vas trabajando en equipo y todo eso, llega un momento en el que ya no puedes, o sea, eres más productivo mostrando cómo funciona la tecnología y delegando que generando código. O sea, como que te multiplicas, por así decirlo. Así que la tecnología no me gustaría cambiarla, no me gustaría especializarme en otra de momento, no. Y veo mucho potencial porque hay mucho mercado abriéndose. O sea, empresas grandes siguen solicitando gente con Elixir, no, se están dando cuenta de que tiene mucho valor. Ya no es nada más una empresa aventurera la que está trabajando con Elixir, ¿no? Tú ya ves empresas como Pepsi, Pinterest, ¿qué otras? Bueno, hay un montón, ¿no? Que últimamente han salido y que tienen muchos proyectos nuevos y que te ayudan a crecer en ese sentido, ¿no? Posiblemente el problema es que de momento la gente que trabaja en Elixir es como que tiene otro nivel, es como que ya gente con experiencia, no, en desarrollo. No es como el junior. Pocos son los juniors que conozco que han llegado, pero les va muy bien justamente por ser juniors. Les enseñan y en poco tiempo empiezan a ser muy productivos y tienen muy buena remuneración por utilizar Elixir, no. Así que al final también eso, eso ayuda mucho, o sea, eso abre el panorama. Lo que quiero decir con esto es No me siento con ánimos de aprender tecnologías nuevas, pero sí me siento con ánimos de especializarme realmente en Elixir y en sistemas distribuidos y en cosas que te den una solución con menor dolor de cabeza.

Ya casi llevamos una hora. Creo que ha sido una charla bastante interesante. De las preguntas típicas que te comenté en un inicio, creo que no me queda ya ninguna. Así que si quería decir algo así como para terminar, ¿qué podría decir de todo esto?

Pues que se animen a utilizar Elixir, que lo prueben. Este, por ahí en un chat que tengo con unos amigos de la universidad me decían, es que yo no quiero aprender otro lenguaje de programación nuevo, yo ya sé Java y con eso me quedo, o ya sé X y ya con eso me quedo. Te diría, no importa si eres el líder de proyecto, si ya estás en un entorno directivo, sí vale la pena que le des una ojeada a Elixir, aunque no lo trabajes, aunque no, porque desde mi punto de vista es la experiencia de mucha gente, porque no nada más es el creador de José Balín, sino es mucha gente. Estamos hablando de Rob Pike, gente que creó Erlang, como este Johan Ström, que se dedicaron a evaluar cómo funcionaban lenguajes de programación anteriores a nuestra era, porque pues nosotros no usamos ese tipo. Bueno, a mí no me tocó trabajar con Fortran, por ejemplo, que trabajaban con Lisp y otras cosas, y querían implementar las funcionalidades en un nuevo lenguaje de programación y que fuera estable y que resolviera problemas para un hardware que no tenía la capacidad que tenía ahora. Y que además de eso pudiera resolver problemas de manera simultánea, en paralelo. Porque en algún momento el principal problema era que todos los lenguajes de programación estaban pensados a que un procesador tuviera solo un core. Los procesadores tenían un solo core. Entonces, cuando llegan los multicore, en ese momento se rompe ese paradigma y ese soporte Sin embargo, Erlang en poco tiempo lo resuelve porque tenía las herramientas y las bases para hacerlo. Y fue el primero que dio todo esto, si mal no recuerdo, ¿no? Con este parámetro que pasaba ahí para poderlo, este, despegar. Y si nos vamos a eso y lo pensamos un poco, la razón de por qué es tan bueno es porque internamente genera sus propios procesos con menos recursos a que si lo hicieras en otro lenguaje, como lo haces por ejemplo con Java, que necesitas crear un nuevo hilo del sistema operativo, y al generar ese hilo del sistema operativo le estás reservando memoria, estás generando más espacio y necesitas más recursos. Entonces obviamente eso tiene un problema ya de diseño desde un inicio. Entonces no lo puedes resolver tú como desarrollador y vas acarreando, vas trayendo todos esos problemas en tu en tu desarrollo sí o sí. Si por el contrario le das una leída a cómo funciona actualmente Elixir y las ventajas que tiene, las convenciones, la documentación, las pruebas unitarias, el ecosistema, la gente que está más agradable que en otros lenguajes de programación porque tienen esa experiencia de saber lo que es que te traten mal, ¿no? O que tengas ese tipo de roces. Yo creo que vale la pena, si no es para que lo sigas usando, sí para que aprendas cómo podrías tú, tu propia comunidad, seguir creciendo, ¿no?

Pues muchas gracias, Iván, por haberte pasado por aquí. Ha sido un placer tenerte en el podcast hoy.

Muchas gracias a ti, Emanuel. La verdad es que este es un espacio que aprecio mucho. Gracias por seguir haciendo tu trabajo y pues ahí estaremos compartiendo mientras se pueda.

Pues este ha sido otro capítulo más de Codeadores. Os dejamos aquí este día de hoy, pero nos vemos la semana siguiente con otro capítulo nuevo. ¡Hasta luego!