Hablemos de ELIXIR

Me encanta cuando los libros tienen una sección de historia al principio.

¿Te pillamos leyendo, pro?

Mmm, sí. Estaba refrescando los datos para el capítulo de hoy sobre el Ixil.

¿Introducción para alquimistas? ¿Estás seguro de que no estás leyendo un libro de magia?

Creo que a Josué Balín no le gusta ese término. Ya sabes, por eso de la cantidad de magia que está ligada a los lenguajes que ocultan mucho.

¡Ah, anda! Y yo que pensaba que leías a Paulo Coelho. Ya sabes... Por El Alquimista. ¿Sigue siendo popular este libro o no?

¿Paulo Coelho? ¡Anda ya! Elixir no es tan antiguo, se creó en 2011.

¿Ahora más de 10 años no es antiguo?

Depende, ¿para qué?

No hay quien os entienda.

El libro ese es de 2018. Para un libro de tecnología sí que es un poco antiguo.

Sé de buena tinta que el autor está trabajando en una nueva edición. Habrá que estar atentos.

Entonces, pro, ¿nos cuentas la historia de Elixir? Ya que la tienes fresca seguro. Antes de continuar, un inciso.

¿Te gustaría apoyar a nuestro canal?

No te olvides de darle a me gusta y si no lo estás suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.

Y además también podemos acompañarte desde tu plataforma de podcast favorita.

Ahora sí, continúa.

El problema con Ruby.

¿Ruby? ¿Por qué hablamos de Ruby? ¿Qué tiene que ver Ruby con Elixir?

Paciencia, Chip. Vamos a empezar por el principio: 2011.

De acuerdo, pero ¿qué tiene que ver Ruby con Elixir?

¡Pues mucho! Hay que tener en cuenta que Josué Balín, el mismísimo creador de Elixir, Fue contribuidor tanto de Ruby como de Rails. De hecho, en su empresa hicieron una de las herramientas más empleadas para autenticar usuarios: Device.

Vale, si Joe se contribuía a Ruby, a Rails y a Device, ¿por qué crear un nuevo lenguaje?

En el capítulo de Ruby comentamos el problema de seguridad cuando procesos o hilos que se ejecutan en paralelo pueden acceder a información general del sistema. No es nada seguro.

El estado global. Sí, tener una variable global en lenguajes como Ruby, Python o Perl tiene esos problemas.

El problema fue la demanda cada vez más de aplicaciones web. Aplicaciones que requieren manejar información concreta y aunque Ruby on Rails fue creado para este fin, Ruby tenía sus problemas.

Sí, ya comentamos esos problemas en el capítulo sobre Ruby. ¿Cuándo llegamos a Elixir?

En ese momento se mezclaron varias circunstancias.

¿Circunstancias? Eso y decir cosas es lo mismo, ¿no?

Chip, me refiero a... ¡Cosas! ¡Circunstancias! Había muchos lenguajes como Ruby siendo implementados en otras máquinas virtuales como JVM y la aparición de Erlang gracias a WhatsApp.

Exacto. Jose descubrió Erlang gracias a un libro de Bruce Tate llamado 7 lenguajes en 7 semanas. Uno de los capítulos estaba dedicado precisamente a Erlang.

Entonces, debido a estas circunstancias, cosas, fue que Jose se decidió a escribir un lenguaje.

Aún no, nos falta otra pieza clave.

¿Otra circunstancia circunstancia?

Otra circunstancia causal. Los lenguajes sobre Beam. Una de las ventajas de la máquina virtual de Erlang, Beam, es que Es como un sistema operativo.

El modo interactivo lo tienen casi todos los lenguajes de programación.

No es solo un modo interactivo. Vim tiene su propia gestión de memoria, su propio programador de tareas basado en reducciones, sus propios procesos.

¿Sus propios procesos?

Sí, no emplea los procesos o hilos del sistema operativo. Crea sus propios procesos.

¡Claro! Entonces por eso necesita su propio programador de tareas.

Y al igual que cualquier máquina virtual, tiene su propio lenguaje máquina.

Vale, pero en JVM también se han implementado muchos lenguajes. ¿Por qué Beam es diferente?

Porque tiene integrado su compilador, el analizador sintáctico, semántico... Disponemos del código que compila el lenguaje Erlang para poder amoldarlo al lenguaje que queramos crear.

Entonces, estas condiciones hicieron que aparecieran muchos lenguajes sobre Beam.

Exacto. Uno de los más avanzados fue Reia, y quizás su autor consiguió tener un poco de visibilidad al prometer Ruby sobre Veeam.

Reia, no me suena.

No tuvo mucho recorrido.

¡Qué pena! Su logo es gracioso.

Era inviable de la forma en que se pensó, porque recordemos que Veeam es una máquina virtual diseñada para Erlang, y por tanto hay características que no se pueden cambiar, como por ejemplo la inmutabilidad de los datos.

Concretando, Jose eligió Erlang porque leyó sus bondades en un libro. Erlang estaba de moda gracias a WhatsApp y, además, encontró un proyecto que prometía Ruby sobre Beam. ¿Todo esto ocurrió en 2011?

Exacto. Jose decidió tomar como base Reia y comenzar a construir Elixir.

¿Copió?

Pidió prestado.

Tony Arcieri El creador de ReiA publicó en 2011 un artículo en el que anunció que cesaba en el desarrollo de ReiA porque quería participar en Elixir. Al parecer, las bases que Jose usó eran del agrado de los contribuidores iniciales. Las editoriales mandan.

Esto lo comentamos en el capítulo de Ruby. Dave Thomas ayudó a la adopción de Ruby en los Estados Unidos.

Exacto. ¡Bien visto! En relación a esto, Dave Thomas también echó un vistazo a Elixir junto con Bruce Tate y ambos se convencieron de que era un gran lenguaje.

De hecho, la editorial de Thomas, Pragmatic Programmers, es la editorial que más libros de Elixir tiene publicados.

Dave Thomas publicó el libro Programming Elixir en 2013 y en ese mismo año, Joel Armstrong se interesó por saber qué era Elixir.

¿Por qué esa curiosidad?

Parece que la noticia se propagó y como Dave Thomas fue el editor del libro de Joe Armstrong sobre Erlang, pues se animó a leer el libro y echar un vistazo a Elixir.

Pues sí que tuvo empuje la editorial.

Sus argumentos fueron bastante convincentes. A ver, Dave explicó que había llegado a Ruby en 1998 porque era un ávido lector de una BBS.

¿Qué es eso?

Pues los foros de los 90. Antes de que se popularizara la web.

Entonces, en 1998 apoyó a Ruby y años más tarde parece que dejó Ruby de lado y comenzó con Elixir.

Exacto. Bueno, según sus palabras. Dice que 15 años después encontró algo nuevo y refrescante en Elixir. En sí, la forma de enseñar programación funcional sin recurrir a textos y conceptos académicos.

Entonces asumimos que Elixir es un lenguaje funcional.

Sí, aunque después volveremos a este punto.

Elixir parte de la idea de Ruby sobre Beam de Ray. E incluso Jose buscaba ese enfoque. ¿Se parece mucho a Ruby?

Creo que alguien dijo que Elixir bien podría ser el hijo de Ruby, Erlang y Clojure.

Exacto. Aunque en un inicio la idea era diseñar un lenguaje como Ruby, como dice Joe Armstrong en su artículo sobre Elixir, finalmente se parece mucho más a Erlang porque tiene que acomodarse a Vim.

Pero agregó elementos que no existían en ese momento en Erlang.

Exacto, en ese momento.

Un poco de competencia no viene mal.

El enfoque de Joe Sevalin para Elixir era muy compatible con las editoriales, porque uno de los pilares del proyecto era documentación de calidad.

Eso facilita mucho el trabajo de publicar libros.

¡Y tanto! El libro sobre metaprogramación es prácticamente un copia y pega de la página web.

Pero, ¿has mencionado los pilares de Elixir? ¿Cuáles son los pilares de Elixir?

Los pilares de Elixir son: extensibilidad, documentación de calidad y herramientas.

Extensibilidad. Esto a mí me suena a programación orientada a objetos, pero de Elixir hemos dicho que es funcional. ¿A qué te refieres?

En verdad se basa en el principio de abierto-cerrado, Chip. Abierto para extender y cerrado para modificar.

Exacto. El ejemplo más claro está en bibliotecas como JSON, porque podemos proporcionar una estructura de datos Y debes saber cómo convertirla en el formato JSON.

Pero podemos convertir nosotros mismos esos datos a un formato que ya entienda la biblioteca y entonces usar la función para generar el JSON, ¿no?

Los programadores de Elixir siempre intentan evitar la burocracia.

¿Burocracia? ¿A eso no le llamaban boilerplate?

Burocracia.

¿Elixir es capaz de reconocer tipos de datos que aún no se han programado?

¡Exacto! Esa es parte de la extensibilidad. Se hace a través de protocolos.

¿Protocolos? Espera, ¿un protocolo para evitar la burocracia?

¡Exacto! Puedes definir un protocolo en tu biblioteca y en un uso futuro podrás definir un comportamiento para un tipo de datos creado en ese momento y del que la biblioteca no tiene constancia.

Suena bien. Es mejor que hacer modificaciones en la biblioteca para cambiar su comportamiento.

Habíamos dicho 3 pilares. La extensibilidad queda clara. La documentación de calidad creo que es fácil saber a qué se refiere. ¿Qué hay de las herramientas?

Hay muchos lenguajes de programación que no tienen un ecosistema.

¿Un ecosistema? ¿Te refieres a esa colección de...? ¿Cosas?

¡No!

Me refería a compiladores, depuradores, editores, constructores, formateadores... Exacto.

Son claros ejemplos de herramientas de que dispone el ecosistema de un lenguaje de programación.

Pero la mayoría de lenguajes los tienen, ¿no?

No, muchos lenguajes como Java, C++ o PHP no disponen de herramientas desarrolladas oficialmente. Es la comunidad la que provee por necesidad de esas herramientas. En el caso de Elixir, desde muy temprano se comenzó a proporcionar un ecosistema rico de herramientas.

A ver si es tan rico. ¿Tiene compilador?

Por supuesto, si no sería un problema.

¿Tiene depurador?

Sí, lo tiene, aunque es algo extraño.

¿Tiene formateador?

Por supuesto.

¿Ejecución de pruebas?

Parece que sí lo incluye.

¿Extractor de documentación?

También.

¿Gestor de dependencias?

Hex, sí, se incluye.

¿Constructor?

Mix, desde el principio.

¿Analizador de código?

Parece que sí, Chip.

Hay que entender que hay muchas herramientas que se proporcionan directamente desde el ecosistema de Erlang y otras que proporciona la comunidad.

Ahora me asalta la duda: habías dicho que Elixir es funcional, aunque he oído que solo Haskell es funcional al 100% o funcional puro.

Desde que aparecieron los lenguajes funcionales hay un debate sobre si un lenguaje es o no funcional.

Como si de un mago de sangre sucia se tratara. ¿Lo pilláis? ¿Alquimia? ¿Sangre sucia? ¿No? Estoy rodeado de muggles.

Tenemos que ver primero: ¿qué hace a un lenguaje funcional? Vamos a enumerar sus características. La primera sería funciones puras. O sin efectos secundarios o colaterales.

Una función determinista, si usas siempre los mismos parámetros, debe retornar siempre el mismo resultado. Como en matemáticas, la suma de 1 y 2 siempre da 3.

¡Exacto! Buen ejemplo. Pero se complica con la computación porque tenemos elementos no deterministas, como la red de comunicaciones, el disco duro, el teclado, el reloj o el generador de números aleatorios. Son datos que no podemos anticipar qué contenido nos darán.

¿No podemos usar ninguno de estos elementos si queremos funciones deterministas?

No, al menos no directamente. Pasemos al segundo: inmutabilidad.

No se puede cambiar el contenido de una variable, pero... si no puedo cambiar una variable, ¿sigue siendo una variable?

También tiene truco. Solo nos dicen que no podemos modificar, pero no dicen nada sobre eliminar.

Si queremos modificar una variable, copiamos su contenido con el cambio en otro espacio de memoria, y cuando el dato antiguo ya no se use, lo eliminamos.

Exacto, como una hoja de papel escrita con bolígrafo. Si necesitas cambiar algo, copias lo necesario cambiando lo que necesites y tiras la hoja anterior.

No suena a que tenga buen rendimiento si tienes que copiar mucho.

Hay atajos y algoritmos que permiten realizar estos cambios inmutables de forma rápida.

¿Qué sigue? ¿Funciones de primera clase?

¡Funciones de alto standing!

¡Nada que ver! Es una forma de decir que las funciones pueden ser tratadas como datos.

Si un código que se ejecuta es un dato, entonces puede cambiarse.

Sí, encierra una gran potencia.

Pero sigue sonando a bajo rendimiento.

Tiene peor rendimiento que los lenguajes imperativos, pero merece la pena y sobre todo en proyectos grandes y con código distribuido.

Discutible.

Evaluación perezosa.

¿No la llaman ahora evaluación diferida, pro?

Para mí siempre será perezosa.

¡No me digas! No hace lo que tiene que hacer hasta última hora. Jeje, me pasa mucho.

Pues sí, justamente eso. No realiza la evaluación de resultados si no es necesario.

¿Esta característica la tiene Elixir?

En verdad no la tiene en el compilador, pero sí está disponible a través del módulo stream para el procesamiento de listas de elementos.

Tiene sentido. ¿Esas son todas?

Esas son las importantes.

Recapitulando: podemos decir que Elixir es un lenguaje funcional porque posee, como mínimo, una serie de características que son: funciones puras, inmutabilidad, funciones de primera clase y evaluación diferida.

Perezosa, pero sí, exacto.

¿Y por qué Elixir no es más usado como Java, por poner un ejemplo?

El círculo vicioso del trabajo. Os voy a contar una historia.

Para eso estamos aquí. Aunque espero que tenga que ver con Elixir porque te vas por las ramas muy fácilmente.

Esta vez tiene que ver con Elixir directamente y su empleo en grandes empresas.

Recientemente vi que se usa en Pepsi, Cabify, Discord, Pinterest... Y en Widmaps. Esa web no es para...

Sí, hay muchas empresas que emplean hoy en día Elixir. Y quizás una de las más grandes, al igual que se hizo con Erlang en Ericsson, Ha terminado eliminando el elixir. Nada más y nada menos que Bleacher Report.

¿Qué empresa es esa?

Una de las más grandes de información deportiva en Estados Unidos.

Ya decía yo.

Es muy grave. De repente llegó el directivo principal y dijo: Todo el elixir debe morir.

¡Qué tétrico!

Pero centrémonos en una mejor historia, pro. Recuerdo que me contaste aquella hazaña de llegar a 2 millones de conexiones concurrentes en una sola máquina. La seguiste por Twitter, ¿no?

Cierto, eso sí fue glorioso. ¿Os acordáis del libro que estaba leyendo antes?

¿Qué libro?

Phoenix Framework de Altenwald. Tiene un capítulo dedicado a la historia, os lo recomiendo.

¡Qué interesante! Le echaremos un vistazo. ¿Seguimos con la historia?

¡Vamos, pro! ¿Cómo llegaron a 2 millones de usuarios concurrentes?

A finales de 2015, Gary Rennie, un entusiasta de Phoenix Framework, quería poner a prueba Phoenix Framework Para ver cuántos usuarios concurrentes conseguía mantener. Según comentó en Twitter, no logró superar los 1000.

La red perfecta para recibir amor y odio a partes iguales.

Y respuestas, Violeta, no solo amor y odio. A veces consigues hasta información.

Bueno, en este caso fue útil.

¿Ves?

Sigue, bro.

La empresa Rackspace, Joe Sevalin y el autor de Phoenix Framework, Chris McCord, se sumaron a las pruebas y comenzaron un proceso de revisión, prueba, corrección... Y vuelta a empezar. Tras los primeros cambios pasaron de esas 1000 conexiones a 50.000 conexiones.

Aún poco sabiendo dónde termina esto.

No interrumpas.

Vale, perdona.

Gaby Zúñiga, CTO de Voice Layer, en aquel momento se sumó a la revisión y realizó cambios internos en la gestión de datos consiguiendo aumentar de 50.000 a 450.000.

Increíble, casi 10 veces más.

Finalmente, entre cambios en Elixir y Phoenix y determinar cómo hacer mejor ciertas partes de la aplicación, consiguieron llegar a 1,3 millones. Y más tarde, con una última optimización de Chris, llegaron a los 2 millones.

¡Toda una hazaña de la escalabilidad vertical! Estaría bien saber los detalles.

Te dejo después el libro.

Pero tengo entendido que hay una empresa que consiguió recientemente 5 millones.

¡Exacto! Discord hizo una publicación en su blog sobre cómo consiguió elevar esa cifra a 5 millones.

Me encantan las historias con final feliz. ¿Ves, pro? Es mejor centrarse en lo bueno.

Conclusiones. Elixir es un lenguaje de programación pragmático surgido de la necesidad de un lenguaje concreto con unos elementos concretos, con unos principios y pilares bien definidos y que ha servido para dinamizar y revitalizar a los programadores de Beam.

De hecho, la conferencia de ElixirConf, que se celebra cada año tanto en Europa como en Estados Unidos, acoge cada vez más entusiastas y empresas que usan este lenguaje de programación, por lo que os animamos a que le echéis un vistazo.

Ahora es vuestro turno. ¿Habéis programado alguna vez con lenguajes como Erlang, Elixir o Go?

¿Preferís las historias de éxito o las historias tristes de empresas abandonando un lenguaje de programación?

Esas historias tienen dos caras. Siempre se abandona un lenguaje y se adopta otro. Como cuando Pinterest dejó Python para adoptar Elixir.

Triste historia ciertamente. ¿Os ha pasado alguna vez en alguna empresa?

Déjanos tus comentarios.

Pues no va mal la competición. ¿Has visto cómo ha subido X?

En Instagram vamos despacio pero a buen ritmo.

Es más fácil subir en LinkedIn. Es una red más profesional.

Discutible. Últimamente se va pareciendo más a Facebook.

¿Le has llamado Facebook? Retira eso.

Sea como fuere, quizá deberíamos avisar a nuestros seguidores de...

¿De que se vienen cositas?

Es posible. En estas fechas todo puede pasar. ¿Habéis echado un vistazo al código de Adviento? Continuará.