Impresiones tras usar Gleam para Advent of Code

• Resolví los 12 días de rompecabezas de Advent of Code 2025 con Gleam, y me impresionaron especialmente sus mensajes de error al nivel de Rust y su estilo funcional centrado en pipelines
• Funciones integradas como echo, fold_until y list.transpose simplificaron la depuración y la resolución de problemas de combinatoria, mientras que la seguridad basada en tipos opción resultó útil para procesar rompecabezas de grillas
• Se señalaron como puntos incómodos la ausencia de IO de archivos y expresiones regulares en la librería estándar, las limitaciones del pattern matching con listas y la sintaxis explícita para comparaciones al usarse repetidamente
• Por las diferencias en el manejo de enteros entre la VM de Erlang y el target de JavaScript, fue necesario usar bigi, y en algunos rompecabezas se resolvió el problema llamando herramientas externas (glpsol)
• En general, expresó que el cambio hacia una forma de pensar funcional hizo más clara la resolución de los rompecabezas, y mostró interés en probar Gleam en proyectos reales, como por ejemplo el desarrollo de un servidor web

---

Advent of Code 2025 y la elección de Gleam

• El autor, que completa Advent of Code cada año, eligió este año el lenguaje Gleam y resolvió 12 días de rompecabezas con él
  • Este año el evento se redujo de 25 a 12 días, y aunque cada problema tenía una dificultad alta, la estructura era adecuada para aprender
• Como el avance de los rompecabezas era rápido y aparecieron problemas complejos antes de tener completo el conjunto de herramientas, se convirtió en un entorno ideal para aprender un lenguaje nuevo

Ventajas del lenguaje Gleam

• Se caracteriza por su sintaxis concisa, mensajes de error del compilador útiles y una retroalimentación amable al nivel de Rust
• Su estilo funcional basado en el operador pipe encaja muy bien con la estructura de los problemas de AoC (parseo → transformación → fold)
• La extensión de Gleam para IntelliJ y el LSP funcionaron de forma estable, haciendo agradable el entorno de desarrollo
• La programación funcional (FP), más que el código imperativo, impulsa un cambio de pensamiento hacia una forma de describir la esencia del problema

Funciones principales y ejemplos de uso en código

• echo: una función simple de salida que permite inspeccionar valores en medio de un pipeline, útil para depurar sin formatear strings
  • También se menciona como inconveniente que, al no haber interpolación de strings, al generar texto se termina usando muchas operaciones <>"
• Tipos opción (dict.get): permiten explorar vecinos de forma segura en rompecabezas de grillas sin hacer verificaciones de límites manuales
• Utilidades de listas
  • list.transpose: simplifica la estructura del rompecabezas mediante una transposición de matriz
  • list.combination_pairs: al generar pares de puntos 3D, permite resolverlo en una sola línea sin loops anidados
  • fold_until: una función fold que puede terminar anticipadamente al cumplirse una condición, eficiente para cálculos iterativos en rompecabezas

Restricciones y puntos incómodos de Gleam

• Ausencia de IO de archivos en la librería estándar, reemplazada con el paquete simplifile
• Las expresiones regulares también requieren una dependencia externa (gleam_regexp)
• Limitaciones del pattern matching con listas: no es posible una forma como [first, ..middle, last]
• Manejo explícito de operaciones de comparación: hay que usar el tipo order, lo que vuelve la sintaxis más verbosa en comparaciones simples

Uso avanzado y casos por rompecabezas

• bigi: se usó para evitar overflow de enteros al compilar al target de JavaScript
• Bitmask XOR: en el Día 10-1, el problema de alternar luces se modeló con una operación XOR para resolverlo de forma eficiente
• Llamada a glpsol: en el Día 10-2, se generó un archivo LP y luego se ejecutó un comando externo para resolver ecuaciones lineales
• Clave de memoización: en el Día 11-2, usar conjuntamente el nodo y el estado como clave permitió completar el cálculo de inmediato
• El rompecabezas final dependía de supuestos sobre la entrada y se resolvió con una simple comparación de áreas (heuristic_area <= max_area)

Conclusión y planes a futuro

• Gleam mostró fortalezas en seguridad y expresividad pese a las limitaciones de su librería estándar
• Pipelines, tipos opción/resultado, funciones de listas y fold_until hicieron más clara la resolución de los rompecabezas
• Planea aplicar Gleam en proyectos reales como el desarrollo de servidores web, y expresó su intención de seguir usándolo en el Advent of Code del próximo año
• El código fuente completo está publicado en el repositorio de GitHub (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

[GN⁺]

Comentarios en Hacker News

• Gleam es de verdad un lenguaje hermoso. Me gustaría que Elixir evolucionara en esta dirección en cuanto a sistema de tipos
  Gleam también corre sobre BEAM, la VM de Erlang, y gracias a eso la concurrencia y el manejo de colas son muy sencillos
  El ecosistema también es excelente. Aun así, me preocupa que desde la era de los LLM, el desarrollo de lenguajes posteriores a 2021 parezca haberse detenido
  De todos modos, Gleam entró justo antes de que se cerrara esa puerta, y espero que pronto los LLM también se pongan al día

  • Me da curiosidad por qué piensas que los LLM hacen que se detenga el desarrollo de lenguajes. Los modelos más recientes incluyen conocimiento hasta este año, y también aprenden bastante bien lenguajes nuevos con solo unos cuantos ejemplos
    Como los lenguajes no pueden ser totalmente distintos ni en sintaxis ni en filosofía, no creo que eso sea un gran problema
  • No es exacto decir que Gleam está construido sobre OTP. La VM de Erlang es BEAM, y OTP es un conjunto de bibliotecas y principios de diseño de Erlang
    Gleam ofrece por su cuenta un subconjunto de OTP seguro en tipos. Consulta la biblioteca relacionada: gleam-lang/otp
  • Sí, correcto, la VM de Erlang es BEAM y no OTP. La implementación de OTP en Gleam no está tan madura como en Elixir o Erlang
  • Yo también armé hace poco mi primer proyecto en Elixir con funciones de LLM, y más bien sentí que esta tendencia podría impulsar la adopción del lenguaje
  • Elixir también está incorporando gradualmente set-theoretic typing. Documento relacionado: gradual-set-theoretic-types

• Este año resolví Advent of Code con Gleam y me dejó bastante impresionado
  Entre las ventajas, el rendimiento es bueno y el language server es sorprendentemente potente. El autoformateo, los imports automáticos y las sugerencias para pattern matching hacen que la experiencia de desarrollo sea excelente
  Como desventajas, el formateador alarga demasiado el código en vertical y, por priorizar la simplicidad, hay mucha repetición como list.map. Además, el ecosistema de bibliotecas todavía es limitado

  • A mí también me sorprendió el rendimiento. No llega al nivel de C, pero es mucho más rápido de lo que esperaba. El language server también funciona bien en casi todos los IDE
    list.map se puede acortar con algo como import gleam/list.{range, map}. También sería interesante portar bibliotecas de C
  • Las desventajas son tolerables, pero la falta de if/else o guards es incómoda. Las ramas booleanas se vuelven demasiado verbosas
  • Hice AoC en F# y me dio una sensación parecida. Repetir namespaces como List.map reduce la descubribilidad (discoverability)
  • El formato de argumentos probablemente se deba al algoritmo de Prettier. Aun así, me parece mucho mejor que el binpacking de clang-format

• Me gusta Gleam, pero me decepciona la restricción en las llamadas a funciones recursivas. No se pueden hacer libremente llamadas a funciones internas
  Sintácticamente es menos elegante que Scheme y, conceptualmente, más simple que Erlang. Aun así, el tipado estático es una ventaja
  También usé OCaml, pero la reproducibilidad del entorno era mala por problemas como los archivos lock de opam. Me gustaría que el ecosistema de SML fuera más grande

  • Pienso algo parecido. Haskell se ve genial en teoría, pero incluso un hello world simple consume muchos recursos
    Idris 2 tiene tipos dependientes y un diseño elegante, pero el ecosistema es pequeño, y PureScript es más práctico que Haskell, aunque está atado al runtime de JS
  • Si te gustan los lenguajes de la familia ML, recomiendo ReScript v12. Está en un punto bastante equilibrado entre OCaml y Gleam

• Al ver la función echo, pensé que sería bueno que un depurador trajera por defecto este tipo de función para inspeccionar resultados intermedios
  Estaría bien poder ver el resultado intermedio de un slice de arreglo o de una cadena de filtros sin modificar el código
  Además, me parece ineficiente usar arreglos bidimensionales como grids. Un arreglo unidimensional + información de límites es más seguro y eficiente

• No conozco bien Gleam, pero viendo list.map(fn(line) { line |> calculate_instruction })
  me da la impresión de que eso se podría escribir simplemente como list.map(calculate_instruction)

  • Sí, correcto, a veces yo también termino borrando una lógica más compleja y dejo esa forma
  • Sí, así es

• Gleam es un gran lenguaje. A mí no me terminó de enganchar mucho, pero me alegra ver que la gente lo disfruta
  Pienso que la combinación Gleam + Lustre podría convertirse en el nuevo Elm

  • Como desarrollador backend, Elm me parecía atractivo, pero me alejé por el conflicto con su creador y la pausa en los lanzamientos. Aun así, esa arquitectura siguió siendo útil en otros proyectos
  • Yo también hice hace poco una app pequeña con Gleam + Lustre, y me fue mucho mejor que con Elm + PostgREST. Ahora pienso usarlo también en proyectos más grandes
  • Revisé Lustre, pero el ecosistema todavía es pequeño. Como no había ejemplos relacionados con autenticación, terminé yéndome con LiveView. Aun así, la ergonomía es buena y ojalá crezca

• Últimamente me pregunto si vale la pena aprender un lenguaje nuevo en esta era de los LLM
  Si es un lenguaje en el que los LLM no fueron entrenados, me preocupa que su utilidad como herramienta sea menor

  • A largo plazo, si los LLM no pueden aprender lenguajes nuevos, entonces habrán fracasado en su objetivo de ser una inteligencia general
  • Hace 1 o 2 años esa preocupación tenía sentido, pero ahora Claude Code escribe código Elixir bastante bien. Aunque haya pocos datos de entrenamiento, no parece ser un problema
  • Claude también maneja bien Gleam. La documentación y la calidad de los mensajes de diagnóstico son buenas, así que a los LLM les resulta fácil aprenderlo. Ofrece diagnósticos al nivel de Rust
    En cambio, Swift tiene una sintaxis compleja y es más difícil de manejar para los LLM
  • Si ves un lenguaje como herramienta, una limitación mayor podría ser la falta de demanda en el mercado
  • Ojalá los lenguajes nuevos no se estanquen por las limitaciones de los LLM

• Cuando vi Gleam hace tiempo, me pareció que no tenía despacho dinámico (interface o type class); me pregunto cómo estará eso ahora

  • Normalmente se resuelve con algo como “pasa una estructura de funciones”. Es un enfoque explícito y, de hecho, está bueno porque evita la complejidad de los genéricos
  • Gleam soporta funciones de primera clase, así que el despacho dinámico es posible. Al final, tanto las type class como las interfaces se pueden expresar con funciones de orden superior

• [first, ..rest] o [first, second] sí se pueden, pero [first, ..middle, last] no.
  Supongo que lo bloquean intencionalmente porque sale caro

• Por suerte, la policía de títulos de blogs llegó rápido al lugar
  Enlace relacionado