Gleam: un lenguaje seguro por tipos en la VM de Erlang

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

Un nuevo lenguaje de tipo estático y estilo ML para la VM de Erlang, Gleam aspira a combinar una fuerte seguridad de tipos con la famosa concurrencia y tolerancia a fallos de BEAM, además de compilar a JavaScript. Los comentaristas elogian su sintaxis limpia, su sistema de tipos Hindley–Milner, su compilador basado en Rust y su ecosistema en crecimiento, pero plantean dudas sobre la madurez de OTP, las herramientas de pruebas y los riesgos a largo plazo de apostar por un lenguaje nicho frente a stacks mainstream como C#, Java o TypeScript. La postura política explícita del proyecto en su sitio web también provoca debate sobre si ese tipo de mensajes pertenece a las herramientas técnicas.

Sentimiento general sobre Gleam y BEAM

  • Muchos comentaristas están entusiasmados: lenguaje de estilo ML con seguridad de tipos sobre BEAM, compilación a JS, buena comunidad, ecosistema en crecimiento.
  • Algunos lo ven como una alternativa sólida a Rescript y un buen complemento para Phoenix/LiveView.
  • Unos pocos sienten curiosidad por BEAM pero dudan en ejecutarlo en producción, viendo BEAM como una “caja negra”; otros responden que BEAM tiene excelentes herramientas de introspección y depuración y que a menudo es más fácil de inspeccionar que Node/JVM.

Sistema de tipos y diseño del lenguaje

  • El sistema de tipos es Hindley–Milner, más cercano a OCaml que a Haskell: tipos de datos algebraicos, genéricos, alias de tipos; sin type classes, sin pureza.
  • Algunos lo consideran “básico” y querrían tipos estructurales/teóricos de conjuntos; otros preguntan qué problemas reales resolvería eso.
  • El pattern matching se ve como fuerte; la sintaxis, en general, recibe elogios por ser limpia.
  • Los argumentos con etiqueta se discuten mucho: a algunos les parecen encantadores y buenos para la legibilidad y el diseño de APIs; otros ven complejidad extra y redundancia.
  • El comportamiento del operador pipe (inserción automática como primer argumento) es controvertido: a algunos les gusta la brevedad, otros sienten que reduce la claridad.
  • Se lamenta brevemente la falta de sobrecarga de funciones frente a Elixir.

OTP, ecosistema e interoperabilidad

  • El soporte nativo de OTP llega vía gleam_otp y gleam_erlang; se describe como experimental, pero ya usado en producción, incluyendo un servidor web reportado como más rápido que Cowboy.
  • Todo el OTP subyacente sigue siendo accesible mediante FFI.
  • Los NIFs y ports en Rust están disponibles (vía herramientas como Rustler), pero requieren cuidado para encajar con el modelo de procesos/planificador de BEAM.

Herramientas, lenguaje de implementación y compiladores en Rust

  • Gleam está escrito en Rust y se cita como un gran ejemplo de una implementación de lenguaje basada en Rust.
  • La discusión aborda pros y contras de Rust frente a Haskell/OCaml para trabajo de compiladores: se elogia el ecosistema de Rust (parsers, LSP, diagnósticos, herramientas incrementales), pero algunos consideran incómodos los enums y el ownership de Rust para ASTs.

Elección de lenguaje, contratación y stacks “no convencionales”

  • Una opinión: usar lenguajes nicho de BEAM en negocios comunes perjudica la contratación y puede forzar reescrituras costosas; los stacks mainstream (C#, Java, Python, TypeScript, quizá Go) son “más seguros.”
  • Contraopinión: contratar por capacidad, enseñar el lenguaje; Erlang/Elixir son simples de aprender, y los stacks no convencionales pueden atraer desarrolladores de mayor calibre. Varias anécdotas afirman que contratar e incorporar gente en Elixir no es difícil.

Casos de uso y debate sobre “scripting tipado”

  • Algunos quieren Gleam como una opción de scripting tipado; otros sostienen que BEAM y los tipos explícitos encajan mal con scripts rápidos frente a shells centrados en cadenas, pero son excelentes para sistemas distribuidos más grandes.

Historia de pruebas

  • Las pruebas giran actualmente en torno a gleeunit, que también funciona en el destino JS.
  • Es intencionalmente minimalista; los mocks no se admiten deliberadamente, con preferencia por la inyección de dependencias. Algunos usuarios querrían más guía o funciones.

Directrices de la comunidad y política

  • El sitio del proyecto declara explícitamente posiciones sociales/políticas (por ejemplo, anti-racista/anti-fascista, pro derechos trans).
  • Esto desencadena un debate secundario: algunos lo ven como una expresión apropiada de los valores del proyecto; otros lo encuentran polarizante y dicen que evitarán o desaconsejarán su uso por ello. Ambas partes acusan a la otra de “meter política” en espacios técnicos.