Cuando se celebra el CodeBEAM de Estocolmo, Ericsson presenta la nueva versión de Erlang/OTP e incluso realiza el lanzamiento de la versión un poco antes o durante la charla. El CodeBEAM America se sucede unos meses después y suelen repetir la charla. Esta vez no fue así y comentaron la siguiente versión, ¿quieres saber qué incluye?
En un artículo anterior sobre CodeBEAM EU 2022 y OTP 25, resumí la intervención de Kenneth Lundin con respecto al nuevo lanzamiento de Erlang/OTP 25. Debo reconocer que no iba a asistir a la charla de Lundin en el Code BEAM America de 2022 porque siempre había sido un refrito y no solía aportar mucho si ya asististe a la conferencia europea. Es como ver los carteles del cine de verano.
Sin embargo, Lundin comenzó con esta diapositiva:
En la diapositiva se muestra el calendario de lanzamientos para 2022 y 2023 de OTP 25 (en azul) y aparece también a partir de febrero de 2023 la versión 26.0-RC1 y las siguientes versiones candidatas (en naranja) y su lanzamiento definitivo en mayo de 2023. Coincidiendo de nuevo con Code BEAM EU.
Esta diapositiva fue algo nuevo y quedé expectante acerca de qué más nos revelaría Lundin.
Características de OTP 26
Esta charla comenzaba de forma original con respecto a la anterior de mayo en Estocolmo y ahora se desmarcaba haciendo repaso de qué vendría con Erlang para OTP 26. Echaremos un vistazo a las características:
Característica maybe por defecto
En OTP 25 se incluyeron las features, una forma de proporcionar al lenguaje con características opcionales que potencialmente pudiesen romper código antiguo. En este caso se tomó la decisión de mantener maybe como opcional porque pasaba a ser una palabra reservada y no podría emplearse como átomo. Al menos no sin agregarle comillas simples ('maybe').
Sin embargo, parece que en esta versión tomaron el camino opuesto y dijeron: bueno, si rompe tu código, deshabilita la característica. Esta forma de proceder me recuerda a una pregunta que Mariano Guerra hizo a Robert Virding acerca de qué le parecía de que con cada nueva versión de Erlang se agregase algo nuevo pero se rompiese o desechase algo antiguo. Creo que mantener maybe como palabra clave no romperá ningún código antiguo porque de hecho, un código hecho para OTP R16 o incluso 17.0, requiere ser modificado para OTP 25.0.
Mejoras en Dialyzer
Dialyzer es una gran herramienta y fue motivo de muchas charlas en el pasado Code BEAM EU. Su atractivo radica en la revisión del código aprovechando características de inmutabilidad que facilitan la navegación del código en frío (sin estar en ejecución) y abrir un abanico de posibilidades en tanto en cuanto a posibles datos de entrada y salida de las funciones para determinad su nivel de corrección.
No obstante, la herramienta es muy lenta y sus mensajes muchas veces son muy difíciles de interpretar. Es por eso que en esta nueva versión (OTP 26), el equipo de Ericsson ha tomado la iniciativa y escuchando a la comunidad ha abordado ambos problemas:
- Modo incremental. Ahora Dialyzer tiene un modo de comprobación incremental que ayuda a acelerar la obtención de resultados.
- Mensajes de error más claros. Ya comenzaron a hacerlo con las funciones de biblioteca de Erlang y ahora lo harán con Dialyzer. Esta iniciativa de facilitar los mensajes de error proveerá una menor frustración a los programadores que se encuentren y enfrenten a códigos difíciles y a sus mensajes de error ya sea en el compilador o en Dialyzer.
Mapas de comprensión (EEP-58)
Sí, en Erlang teníamos las listas de comprensión, binarios de comprensión y ahora tendremos mapas de comprensión. No deja de ser una característica propia del lenguaje de poder realizar de forma mucho más semántica un map-reduce.
Si quieres saber más sobre este tipo de dato en listas y binario, echa un vistazo al capítulo 2, el lenguaje en el libro Erlang/OTP Volumen I: Un Mundo Concurrente.
En mapas, esta construcción es como sigue:
#{ Key => Value || Key := Value <- MapOrIterator}Es decir, un código que antes escribíamos así:
Map = #{ a => 1, b => 2, c => 3, d => 4},
maps:map(fun(K, V) -> V * 2 end, Map).
%% #{a => 2,b => 4,c => 6,d => 8}Ahora podemos escribirlo así:
Map = #{ a => 1, b => 2, c => 3, d => 4},
#{K => V * 2 || K := V <- Map}.
%% #{a => 2,b => 4,c => 6,d => 8}
Pero además podemos hacer cambios en la clave (K) y no solo en el valor, y agregar una coma para incluir todas las condiciones que necesitemos:
Map = #{ a => 1, b => 2, c => 3, d => 4},
#{atom_to_list(K) => V * 2 || K := V <- Map, V rem 2 =:= 0}.
%% #{"b" => 4,"d" => 8}Distribución de Erlang sobre kTLS
Esta característica tengo que estudiarla un poco más en profundidad. Por lo que entendí de la charla, propone realizar la distribución de Erlang usando kernel TLS para hacer más segura la comunicación entre nodos. Realizaré unas pruebas y os hago saber pronto en un nuevo artículo en qué consiste, sus pros y contras.
Shell
Este ha sido el aspecto de OTP 26 que más estoy esperando. Solo decir que finalmente emplearán para construir la shell otra librería diferente permitiendo mucha más interactividad en los autocompletados, el histórico e incluso la introspección en el código que se va escribiendo. Este tema quiero ampliarlo mucho más en un nuevo artículo y seguramente a través de un vídeo también. ¡Déjame un comentario con tus preferencias!
Conclusiones
Siempre quedo contento con cada nueva característica en lenguajes de programación. Hace ya tiempo que solo me ilusionan en lugar de preocuparme e iré publicando novedades con respecto a las promesas anteriores de la distribución de Erlang con kTLS y cómo se vea la nueva shell.
¿Cómo ves estas características en OTP 26? ¿Y la trayectoria de Erlang/OTP en estos últimos años? ¡Déjanos un comentario!
