Erlang/OTP 29.0

 (erlang.org)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El daemon SSH ahora desactiva por defecto los servicios de shell y exec, por lo que los usuarios autenticados ya no pueden ejecutar código Erlang arbitrario a menos que se configure explícitamente
  • Al iniciar el daemon SSH, el subsystem SFTP tampoco se habilita ya por defecto, reforzando así la seguridad predeterminada
  • Se agregó el atributo -unsafe, que permite marcar funciones inseguras, y el compilador ahora genera advertencias por defecto cuando se llama a funciones que Erlang/OTP siempre considera inseguras
  • xref ahora puede encontrar llamadas a funciones inseguras y funciones sin documentación, y el filtrado del atributo ignore_xref pasó a ser manejado por xref mismo
  • En la configuración predeterminada de SSL, x25519mlkem768 se convirtió en el grupo de intercambio de claves más preferido, y el algoritmo de intercambio de claves por defecto de SSH también cambió a mlkem768x25519-sha256, que combina ML-KEM-768 y X25519
  • En la ruta de código predeterminada del sistema Erlang, el directorio de trabajo actual . pasó del primer al último lugar, cambiando el orden de carga
  • Ya no se ofrecen builds de Erlang/OTP de 32 bits para Windows
  • Se implementaron los native records de EEP-79, y en Erlang/OTP 29 se consideran una función experimental
  • Se agregaron el guard BIF is_integer/3, las comprehensions multivalor basadas en EEP 78 y el enlace de variables dentro de comprehensions mediante la funcionalidad compr_assign
  • El compilador agrega advertencias por defecto para catch, la exportación de variables fuera de subexpresiones, and/or y patrones match alias como {a,B} = {X,Y}, con opciones para desactivar cada una
  • Las pruebas de guard antiguas se eliminarán del lenguaje en Erlang/OTP 30, y la advertencia existente sobre el uso de guards obsoletos seguirá aplicándose
  • Con io_ansi se pueden imprimir secuencias ANSI/Virtual Terminal Sequence en la terminal, y con ct_doctest se pueden probar ejemplos en la documentación de módulos Erlang y en archivos de documentación

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Comentarios en Hacker News

  • Las mejoras se ven bastante bien. Desactivar por defecto el daemon SSH y también SFTP por defecto es un buen cambio desde el punto de vista de seguridad
    El módulo io_ansi también se ve bastante interesante. Ahora mismo Erlang no suele ser de lo primero que se piensa para crear aplicaciones complejas de línea de comandos, pero si esto entra en la librería estándar, parece que podría ayudar mucho en el futuro. La forma en que fwrite funciona de manera natural entre nodos también es justo esa ventaja que uno espera de Erlang
    La incorporación de Native Records también es interesante. Ahora mismo en Elixir se siente como que, según el caso, se mezclan records, tuplas y mapas, así que da curiosidad ver cómo se va a usar esto en adelante. Como dice el EEP, no parece que los records existentes vayan a desaparecer por completo, pero sí se ve como una mejora importante
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • No creo que el daemon SSH se haya activado o iniciado automáticamente alguna vez. Aunque la redacción de ambos puntos es distinta, parece que lo que quieren decir es que, al iniciar el daemon SSH, los componentes listados ya no se arrancan por defecto
      El daemon SSH ahora sigue el principio de secure by default al tener deshabilitados por defecto el shell y el servicio exec. Si no se configura explícitamente, evita que usuarios autenticados puedan ejecutar código Erlang arbitrario
      El subsistema SFTP tampoco se activa ya por defecto al iniciar el daemon SSH

  • Para quien tenga curiosidad por qué significa OTP en Erlang/OTP, originalmente es un conjunto de librerías y principios para construir de forma estandarizada aplicaciones de alta confiabilidad y tolerantes a fallos para telecomunicaciones
    Vale la pena leer al menos por encima la introducción de “OTP Design Principles” para entender la idea básica
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • Si tu app en producción está por debajo de 29, probablemente convenga actualizar lo antes posible a esta versión o a la última versión con parches. Acabo de desplegarla en producción y el escaneo automático de seguridad detectó 2 CVE CRÍTICOS con fechas de febrero a mayo de 2026, además de varios elementos de riesgo HIGH

    • ¿Hay una lista?

  • Me pregunto si todavía hay gente usando Erlang para proyectos nuevos
    Sé que aquí hay mucha gente a la que le gusta Elixir, pero me refiero a Erlang puro
    Si todavía usas Erlang, me da curiosidad por qué lo prefieres sobre Elixir

    • Sí, incluso este año. Hay un nuevo trabajo de IoT basado en AtomVM, un servidor de aplicaciones escrito en Erlang y un framework TUI que todavía está en desarrollo
      Elixir no me da una ventaja práctica real frente a Erlang. Seguro que puede tener ventajas, pero Erlang encaja mejor con mi forma de pensar. También me gustaría intentar aprender o pedir ayuda en algo más parecido a una comunidad social, pero no encuentro bien un espacio que me funcione

  • ¿Alguien puede explicar la arquitectura interna?

  • Me da curiosidad cómo van a encontrar su lugar los records dentro del ecosistema

    • Estaba a punto de decir “¿pero si los records existen desde hace décadas?”, pero luego leí el changelog
      Interesante. Me pregunto si algún día habrá un mundo en el que Elixir compile mapas a native records

  • ¿Alguien sabe si WhatsApp sigue basado en Erlang?

    • Sí
      Han usado Erlang desde principios de los 2010, y por esa época la industria tecnológica se enteró de que WhatsApp soportaba más de 400 millones de usuarios activos con alrededor de 30 ingenieros
      En ese entonces contacté a uno de sus ingenieros y, cuando yo vivía en EE. UU., me respondió amablemente por correo varias preguntas. Al final hasta fuimos por un café y seguimos en contacto hasta hoy
      Diría que Erlang sigue siendo una parte importante de WhatsApp
    • Por una presentación en Code BEAM Europe 2025, parece bastante probable que sí: https://www.youtube.com/watch?v=tC435RGwRCI
    • No lo sé de primera mano, pero me fui en 2019 y los repositorios públicos relacionados con Erlang de WhatsApp siguen bastante activos. Hasta donde sé, tampoco es que Erlang se haya expandido por todo Meta, así que si WhatsApp hubiera dejado Erlang, no habría mucha razón para seguir haciendo trabajo con Erlang después de eso
    • Sí. Un ex empleado mío trabaja ahí ahora
    • Sí. Usan Erlang y también cada vez más Rust

  • Así que añadieron soporte para el atributo -unsafe, excelente momento para reescribirlo en Rust /s

  • La verdad no sé quién usa Erlang. He usado Rails y también probé Phoenix, y se me hizo mucho más difícil lograr cosas con Phoenix
    No entiendo el entusiasmo por Phoenix
    Para una sola persona desarrollando, Rails probablemente sea el sistema de web apps más productivo. Los LLM también escriben código Ruby on Rails muy bien. Aunque el corpus de entrenamiento de Python es enorme, en mi experiencia lo hacen mucho mejor que con Django
    Las apps experimentales las escribo en Rails, y cuando se estabilizan las reescribo en Go. Si el alcance de la app no está claro, irse directo a Go consume muchos más tokens, mientras que con Rails es muy eficiente
    Hoy en día React o Angular ya ni hacen falta; en Rails uso Hotwire y en Go uso HTMX
    Incluso el foro de Erlang usa Discourse, que está hecho con Rails

    • Llevo escribiendo apps en Elixir a tiempo completo desde 2016. A los clientes les encanta no ver caídas. De hecho, todas las aplicaciones que he desplegado en producción en los últimos 10 años han tenido 100% de uptime, excluyendo fallas de hardware, sistema operativo o red que están fuera de mi control
      Te convendría ampliar un poco la perspectiva
    • Yo diría que Rails solo es más rápido que Phoenix, en velocidad de desarrollo, más o menos el primer día. Después empiezas a chocarte con lógica implícita, cosas como method_missing, y terminas gastando más tiempo en entender cómo funciona todo
      Elixir/Phoenix es mucho más explícito en ese sentido, así que para mantenimiento a largo plazo, o sea después de la primera semana, resulta mucho más cómodo. No hay estado oculto, no tienes que andar buscando de dónde sale ModuleName.method(params), ni configurar algo especial para ejecutar ese método: basta con pasarle los argumentos correctos. La desventaja sería más bien que hay una biblioteca de paquetes lista para usar más pequeña
    • ¿Quieres adivinar qué usa Ruby Discord?
    • Phoenix resulta interesante sobre todo por OTP, los channels y LiveView. Pero LiveView probablemente no sería mi elección en 2026, y si no necesitas ese tipo de funciones, puede que resulte menos atractivo
      Ecto tampoco está mal
      Claude Code escribe código Elixir bastante bien
      Sorprendentemente, con o sin LLM, uno es más productivo usando la tecnología que ya conoce
    • Hay una ironía total en decir “si el alcance de la app no está claro, irse directo a Go consume muchos más tokens, mientras que con Rails es muy eficiente”. Después de escribir todo eso, básicamente acabas de admitir que ni siquiera eres tú quien escribe el código.