En junio de 2016 fue la última vez que hablé sobre una liberación de Erlang y desde ese momento (hace ya 2 años y medio) ha llovido bastante. El equipo de Elixir ha ayudado a Ericsson con las últimas liberaciones así que, ¿qué tal si vemos qué mejoras han integrado en OTP 21?

Antes de nada, como también se me olvidó comentar las mejoras introducidas en OTP 20 voy a realizar aquí un resumen de todas las mejoras y después iremos profundizando en las más importantes. Hay otras como las mejoras en SSL a las que no entraré muy en detalle, solo comentar que se han realizado para ir mejorando el soporte de seguridad y eliminar protocolos o algoritmos de cifrado desfasados o marcados como inseguros.

OTP 20

Además de la publicación oficial de los cambios (en inglés) me ha gustado leer la lista alternativa de nuevas mejoras que se introducen en OTP 20 de la mano de Brujo Benavides en My Erlang/OTP 20 Highlights. Puedo simplificar las mejoras como:

• Programadores Sucios (o Dirty Schedulers) activados en BEAM y con soporte SMP. Esto está relacionado con las dirty BIFs y el dirty GC (recolector de basura). He encontrado mucha información sobre los cambios que realizan a nivel de uso de BIFs (o NIFs) estos programadores y considero que será mejor tratarlos en otro artículo por su extensión.
• Mejoras de rendimiento tanto empleando literales como en tablas ETS de más de 256 elementos (salvo con ordered_set) así como optimizaciones en la compilación, concordancias con mapas y en los temporizadores.

En la lista de Brujo podemos ver además otras mejoras interesantes como:

• Escribir ports y pids en la shell. Esto es muy interesante. Hasta el momento cuando queríamos escribir un PID en la shell, había que recurrir a estratagemas como erlang:list_to_pid/1 o en consola pid/3. De esta forma ahora podemos escribir directamente no solo el PID en su formato: <0.70.0>; sino también los puertos.
• Retro-llamadas opcionales en comportamientos. Esto es genial. Cuando se escribe un servidor empleando gen_server siempre debíamos de agregar las retro-llamadas code_change/3, terminate/2 y handle_info/2. Gracias a este cambio estas retro-llamadas ahora son opcionales y no se requiere su implementación.
• Unicode everywhere!. Sí, se ha modificado el módulo string y se ha implementado el uso de unicode incluso a nivel de átomos siendo posible ahora incluso tener un átomo con emojis.

Hay otras muchas mejoras como adición de funciones a módulos para el tratamiento de árboles, diccionarios o tablas ETS así como mejoras en el sistema de pruebas common_test (o ct) pero quiero centrarme principalmente en funcionalidades generales.

OTP 21

Sobre los cambios y mejoras en OTP 21 me gustaría señalar las siguientes que veo más importantes:

• Mejoras significativas en I/O. El sistema de Entrada y Salida (en inglés IO o I/O, como el módulo io) ha sufrido un cambio drástico en su implementación para mejorar su rendimiento. Gracias precisamente a los programadores sucios de los que hablamos antes en las mejoras de OTP 20. La mejora es significativa sobre todo en la gestión de ficheros.
• Mejoras en compilación. La compilación se ha mejorado consiguiendo una optimización del 20% gracias a cambios como el modo en que las tuplas son empleadas internamente.
• Mejoras en conectividad de red. Se emplean los nuevos mecanismos disponibles en los sistemas operativos para polling haciendo más eficiente la capa de red.
• Mejora en los mensajes de procesos enlazados y monitorizados. Esta mejora ha supuesto un cambio significativo en los supervisores. Hasta ahora cuando teníamos escenarios donde los procesos son creados y destruidos de forma constante el supervisor recibe un mensaje y es bloqueado internamente sin poder realizar ninguna acción. Además, si el supervisor tiene muchos procesos enlazados este proceso puede ser costoso y demorar la entrega o envío de otros mensajes. Esta capa ha sido reescrita y se ha eliminado el bloqueo completamente. Esto se traduce en una mejora de rendimiento para estos escenarios.
• Escribe tu propio sistema de distribución. Esto también da para un artículo y he estado jugando últimamente mucho con este sistema para evitar el uso de epmd en instalaciones que empleasen Docker por lo que hablaré en un próximo artículo más en detalle sobre cómo funciona esta característica.
• Nuevo sistema de anotaciones (logs). Sí, ya sabíamos que error_logger tenía sus deficiencias y gracias a otros proyectos como lager o Logger de Elixir el equipo de Ericsson ha podido reescribir con esas y otras ideas el sistema de anotaciones haciéndolo más efectivo.
• Nueva retro-llamada para los comportamientos. Se ha agregado handle_continue/2. Esta retro-llamada corresponde a un uso necesario dentro de Erlang/OTP para ciertos escenarios donde el inicio de un proceso es largo pero puede realizarse en segundo plano. Hasta este momento había que recurrir a la artimaña de enviarnos a nosotros mismos un mensaje para gestionar vía handle_cast/2 o handle_info/2 pero esto podría causar muchos problemas, por lo que esta forma de aislar ese proceso para ejecutarse solo al inicio lo hace indispensable para escribir código más claro.

Además de estas mejoras se ha seguido profundizando en otras como la adición de más guardas para el uso de mapas como erlang:is_map_key/2 o erlang:map_get/2 que permiten obtener un valor o una clave de un mapa para emplearlo en las guardas.

¿Qué es lo mejor?

Realmente podría decir que lo mejor es ver el impulso hacia las mejoras de rendimiento para BEAM. Esto no solo beneficia a Erlang sino también a Elixir. Muchas de estas mejoras han sido propuestas desde los equipos de desarrollo de Elixir que han trabajado codo con codo con los equipos de soporte y desarrollo de Erlang en Ericsson.

Lukas Larsson explicaba en este artículo (en inglés) todos los cambios realizados en la versión OTP 21 en base a mejorar el rendimiento de la capa de E/S para ficheros, red e incluso la entrada y salida estándar del sistema. También todas las mejoras que comenté antes. En este otro artículo de Michał Muskała (desarrollador de Elixir) que hace un repaso a esas mejoras desde código escrito en Elixir empleando esa versión de BEAM.

Además vemos que los comportamientos siguen evolucionando de forma positiva. No solo ya podemos (y debemos) olvidarnos de gen_fsm sino que gen_statem ha traído mejoras que se están propagando al resto de comportamientos y seguiremos viendo mejoras en las próximas versiones de Erlang.

¿Qué es lo siguiente?

El equipo de Ericsson está trabajando activamente en OTP 22 y ya han señalado algunas mejoras que incluirá OTP 22 apuntando de nuevo a optimizaciones de rendimiento y las constantes mejoras y cambios en las capas de TLS y SSL. No obstante no se ha desvelado aún nada nuevo a ser incluido de momento en esta liberación. Esperaremos a ver qué nos depara BEAM con las siguientes comunicaciones de su equipo de desarrollo.

¿Crees que Erlang está consiguiendo más movimiento gracias a estas liberaciones? ¿Has considerado lanzarte a usarlo? ¿Consideras que quizás estas mejoras pueden ser más producto de Elixir y su tracción? ¡Déjanos un comentario!