Elixir v1.20: Ahora es un lenguaje con tipado gradual

Artículo original ↗ Discusión en Hacker News ↗

Resumen del tipado gradual de Elixir 1.20

  • El sistema de tipado gradual se basa en “strong arrows” y tipos teóricos de conjuntos (uniones, intersecciones, negaciones).
  • Todavía no hay nueva sintaxis visible; infiere tipos a partir de construcciones existentes (pattern matching, guards).
  • El objetivo del diseño es la solidez sin casts en tiempo de ejecución en los límites tipado/no tipado. El bytecode generado es semánticamente idéntico al código no tipado, así que la complejidad asintótica no cambia.
  • Se planifican anotaciones futuras; la información de tipos puede propagarse mediante funciones “strong”, al menos dentro de un módulo.

Rendimiento, Dialyzer y herramientas existentes

  • Varias personas informan de compilación notablemente más rápida en proyectos reales tras la actualización.
  • El success typing de Dialyzer se considera limitado en la práctica, especialmente con dependencias circulares y protocolos; algunos esperan que el nuevo sistema sea más útil.
  • Algunos siguen usando typespecs בעיקרamente como documentación; el compilador cada vez detecta más problemas antes que Dialyzer de todos modos.

Debate entre tipado dinámico y estático

  • Muchos están entusiasmados: los tipos encuentran errores reales “gratis”, mejoran la confianza en bases de código grandes y pueden ayudar a agentes de IA mediante mejores restricciones y retroalimentación de errores.
  • Otros argumentan que la tolerancia a fallos de Elixir/BEAM (“let it crash”, árboles de supervisión) ya mitiga muchos errores en tiempo de ejecución; rara vez ven que errores de tipos provoquen caídas.
  • Algunos ven los tipos como una característica “agradable pero de nicho” para Elixir; otros dicen que la falta de tipos estáticos antes les impedía adoptarlo seriamente.

Curva de aprendizaje, ergonomía y seguridad

  • Quienes empiezan reportan que Elixir/Phoenix es potente pero difícil de aprender: el uso intensivo de macros, la magia en tiempo de compilación, los paréntesis opcionales y la sintaxis de listas de keywords son obstáculos frecuentes.
  • Los conceptos de BEAM (procesos, supervisión, estrategias de reinicio) resultan abrumadores para algunos; otros comparten artículos y libros para cubrir esa brecha.
  • La seguridad de Phoenix LiveView se debate: algunos se preocupan por llamar a handlers arbitrarios mediante websockets secuestrados; otros subrayan que cualquier cliente puede enviar cualquier mensaje y que la autorización debe imponerse mediante estado y guards, igual que en HTTP.

Comparaciones y ecosistema

  • Gleam se menciona con frecuencia: totalmente tipado estáticamente, sintaxis similar a Rust, compila a BEAM y JS, pero carece de macros y de la madurez de Phoenix/Ecto.
  • Algunos prefieren Rust/Go/OCaml por un tipado estático “real” y un despliegue más sencillo; otros valoran más la concurrencia y la tolerancia a fallos de BEAM.
  • La estabilidad a largo plazo de Elixir y los cambios mínimos incompatibles son muy elogiados, aunque las oportunidades laborales se perciben como limitadas en algunas regiones.