Elm 0.19.2 mejora la velocidad de compilación

• Elm 0.19.2 es el primer paso en una serie de lanzamientos pequeños para incorporar mejoras del compilador antes de llegar a Elm 1.0
• En una gran base de código de Elm, la compilación desde cero se midió en 5.7 segundos y las compilaciones incrementales posteriores en menos de 350 ms, reduciendo la posibilidad de interrumpir el flujo de concentración durante el desarrollo
• Esta mejora se enfocó en reducir las asignaciones durante el parsing; en un experimento con 850 mil líneas se observó una reducción del 20% en la cantidad copiada por el GC, una disminución del 10% en el uso máximo de memoria y una mejora del 7% en la velocidad total
• En pruebas con proyectos reales, el grado de mejora varió; en un caso de compilación desde cero de 351 módulos, bajó de 4.981 segundos a 2.595 segundos, volviéndose 1.9 veces más rápida
• Las ideas de rendimiento y lenguaje surgidas del trabajo en Acadia se incorporarán progresivamente en futuros lanzamientos sin romper la compatibilidad, y tras los últimos ajustes el plan es llegar a Elm 1.0

---

Compilación más rápida en Elm 0.19.2

• Elm 0.19.2 es el primer lanzamiento que incorpora en Elm, en unidades pequeñas, las mejoras acumuladas del compilador
• Un compilador rápido reduce las situaciones en las que los desarrolladores cambian a una pestaña del navegador y pierden la concentración
  • Si la compilación incremental tarda menos de 400 ms, casi no queda margen para pasar a otra tarea
• El rendimiento con una base de 850 mil líneas de Elm es el siguiente
  • Compilación desde cero: 5.7 segundos
  • Compilación incremental: menos de 350 ms
• El cambio real se concentró en reducir las asignaciones durante el parsing
  • 20% menos cantidad copiada por el GC
  • 10% menos uso máximo de memoria
  • 7% más de velocidad total
• En programas de más de 500 mil líneas se pueden esperar mejoras moderadas, y en programas más pequeños el compilador de Elm sigue siendo muy rápido
• En pruebas en entornos reales, el grado de mejora varió según el proyecto
  • Algunos proyectos mejoraron levemente
  • En el caso de compilar 351 módulos desde cero, bajó de 4.981 segundos a 2.595 segundos, una mejora de 1.9 veces
• La nueva versión se puede obtener en el lanzamiento de Elm compiler 0.19.2

Próximos lanzamientos rumbo a Elm 1.0

• Las ideas obtenidas del trabajo de compilador relacionado con bases de datos llamado Acadia también se aprovecharán en Elm
  • Acadia se encuentra actualmente en alfa privada
  • La difusión pública está prevista para finales de este año
• Las ideas que se incorporarán a Elm incluyen tanto mejoras de rendimiento como funcionalidades del lenguaje
  • Ej.: un parser más rápido
  • Ej.: tipos equatable, hashable
• Estos cambios se incorporarán como una serie de lanzamientos pequeños que no rompen la compatibilidad, para integrarlos de forma natural en Elm
• En la etapa final de ajustes, el plan es pasar a Elm 1.0
• Quienes estén conociendo Elm por primera vez pueden empezar con los ejemplos en línea y la guía
• Como Elm 0.19.2 es un lanzamiento de parche, los proyectos existentes pueden descargar la nueva versión y usarla de inmediato

[GN⁺]

Opiniones en Hacker News

• Hoy en día veo a Elm más como un lenguaje de investigación con mucha influencia
  Tiene un enfoque muy claro, no hay roadmap público ni soporte oficial, y el liderazgo parece tener muy poco interés en construir una comunidad o un equipo core
  Aun así, la experiencia de trabajo es realmente buena, y como resultado han surgido varios forks y proyectos derivados. En la reciente conferencia de Gleam, Louis Pilfold bromeó diciendo que “cada usuario de Elm mantiene su propio compilador”, y en la práctica hay al menos 6, con 2 más anunciados el mes pasado
  Me alegra que Evan avance hacia 1.0, y ojalá después de llamar a Elm “algo terminado”, uno de los proyectos sucesores pueda asumir el trabajo difícil de unificar forks y hacer crecer la comunidad
  Personalmente, si la próxima vez busco algo parecido a Elm, pienso mirar Gleam + Lustre. La combinación de una comunidad y mantenedores que se preocupan por el diseño se ve buena, y funciona tanto en frontend como en backend

  • La trayectoria de Elm fue bastante extraña, pero creo que llamarlo lenguaje de investigación es acertado
    En algún momento se promovió con mucho entusiasmo, había muchos posts de blog y charlas, y bastante entusiasmo y adopción
    Luego el autor prácticamente desapareció y el proyecto se detuvo
    Claro, es su proyecto y tiene derecho a hacerlo, pero creo que debería haber establecido mejor las expectativas desde el principio. La difusión activa ayudó a expandir las ideas, pero también hizo que los desarrolladores sintieran que de pronto los habían abandonado
  • Lo mejor de Elm es que tiene una fuerte sensación a Haskell. Hace unos años hice cosas divertidas con Elm
    Lo segundo mejor es la filosofía de “si compila, funciona”. Sinceramente, en buena parte de Rust se puede obtener una sensación parecida. Se siente menos a Haskell, pero tiene algo de la sombra cálida de sus ancestros funcionales
  • Gren parecía un sucesor bastante capaz, y la comunidad también es activa y muy dispuesta a ayudar
  • Yo soy uno de ellos. Extendí el lenguaje para agregar varias comodidades y, en esencia, hice que admitiera inyección de dependencias mediante un canal de errores adecuado y tipos suma que pueden borrarse
    Elm es un buen lenguaje, pero Evan realmente no parece interesado en construir algo verdaderamente útil, y la gestión general del lenguaje es un desastre
  • Como Elm es tan bueno, parece que la gente se decepciona con su estancamiento. Pero ese estancamiento también es parte de lo que hace bueno a Elm

• En 2023 escribí sobre por qué todavía usaba Elm
  https://taylor.town/elm-2023
  Ahora, en 2026, sigo usando Elm por las mismas razones :)
  Además, Claude parece encajar muy bien con Elm
  https://taylor.town/diggit-000

• Hace unos 2 años hice un experimento de vibe coding con ChatGPT para crear un juego de Snake para el navegador en Elm, un lenguaje que me encanta
  En ese momento era bastante tosco, y concluí que los modelos de lenguaje grandes podrían matar a Elm
  Ahora uso Elm en producción, y los modelos de lenguaje grandes han mejorado mucho. De hecho, creo que Elm podría aumentar su adopción porque ahora es un lenguaje ideal para los modelos de lenguaje grandes. Es más simple que la mayoría de los lenguajes, estable, y trae dentro del lenguaje una arquitectura con opiniones fuertes, por lo que las bases de código terminan pareciéndose mucho entre sí

  • Gracias a la IA también me metí más en la música, compré un teclado MIDI y configuré un software DAW decente
    También estoy creando más cosas en Rust y leyendo más documentación de Rust. Los modelos de lenguaje grandes no deben ser una excusa para no aprender aquello para lo que se usan; si se usan así, eres un mal ingeniero
    Los modelos de lenguaje grandes te dan tiempo para investigar y aprender de modo que puedas mantener los resultados que recibes. Si entiendes el problema, también puedes escribir mejores prompts
  • Decir que los modelos de lenguaje grandes podrían aumentar la adopción de Elm es a la vez cierto y no tanto
    Al final depende de cuánto Elm haya en los datos de entrenamiento y en el RLHF. Estoy de acuerdo en que los frameworks o lenguajes estructurados hacen que las bases de código se parezcan más y sean más fáciles de generar
    Pero eso por sí solo no alcanza, y normalmente la adopción por parte de desarrolladores es un debate mucho más complejo en sí mismo
  • Puede que haya mejorado, pero me decepcionó mucho ver cómo agentes como Claude Code seguían tropezando con los espacios en blanco significativos de Elm
    Maneja Python muy bien, así que me pareció extraño, y Elm está entre los lenguajes modernos más estables. Tan estable que la gente se queja de que no cambia. Dicho eso, la última vez que lo intenté fue hace alrededor de un año, así que supongo que ahora estará mejor
  • Ese punto de vista es válido. Nunca lo había pensado así, pero si el ecosistema no avanza, creo que igual me seguiría dando dudas

• ¿Ya se resolvieron las limitaciones relacionadas con JavaScript? Si mal no recuerdo, para integrarse con JavaScript había que usar el mecanismo de Ports de Elm, y creo que no permitían escribir wrappers directamente
  También recuerdo que hubo controversia cuando alguien hizo un fork para poder escribir wrappers de JavaScript directos o usar FFI

  • FFI todavía se maneja en su mayor parte con ports. Para la parte de vistas también se usan web components
    Es una decisión intencional, y es muy probable que se mantenga hasta 1.0 y también después

• No sabía que este proyecto seguía vivo. No lo digo con sarcasmo, pero pensé que ya se había terminado.

  • El proyecto estaba muerto. La versión anterior había sido hace 7 años, y después de que su creador dejó de darle mantenimiento, la comunidad no logró superar el modelo BDFL y quedó estancada.
    Así que estaba muerto, y ahora básicamente acaba de revivir. Tengo entendido que, mientras tanto, la comunidad se marchitó bastante.
  • No estuve profundamente involucrado en la comunidad, pero conozco a gente que participaba en ese momento y, por lo que entendí, la eliminación de los operadores infijos personalizados hizo que se perdiera mucho apoyo de la comunidad.
    Era una funcionalidad muy popular, pero se eliminó porque al creador del lenguaje no le gustaba, aunque la comunidad insistió mucho en que se mantuviera.
    Técnicamente quizá fue la decisión correcta, pero socialmente fue muy impopular y probablemente fue una mala decisión.
  • Me alegra que haya vuelto. Elm siempre tuvo una elegancia sorprendente que dan ganas de apoyar.
  • Durante los últimos 2 años he usado Elm profesionalmente en una empresa muy rentable y sin complicaciones.
    No lo conocía antes de entrar, pero como tenía experiencia con React, Redux y demás, lo aprendí rápido.
    La comunidad de Elm llamaría a esto una funcionalidad. ¿Cuánto código React escrito hace 6 a 8 años funciona hoy de forma completamente idéntica en el toolchain actual de React?
    Los valores son totalmente distintos. El buen código React de 2026 se parece al código Elm que compila desde 2016.
  • Yo también pensaba que la comunidad alrededor de Elm básicamente había desaparecido. Aun así, parece que el mantenedor único y creador todavía sigue ahí.
    Nunca usé Elm más allá de tutoriales, pero hace poco hice una app full-stack en Gleam y usé principalmente agentes de programación. Al principio controlé la estructura del código con bastante rigidez, y ese proceso encajó bastante bien.

• Me interesa más lo que viene después de Elm 0.19 que Elm 1.0. La 0.19 fue la versión que bloqueó todos los módulos nativos que no estuvieran oficialmente aprobados por el autor de Elm, y para mí eso marcó prácticamente el final de Elm.

• Es difícil imaginar un anuncio peor para el camino hacia 1.0. ¿A quién le importa? Si no hay soporte de localización ni de accesibilidad, no tiene sentido llamar 1.0 listo para producción a un framework de UI.
  Creo que limitar el alcance con el que los colaboradores de terceros pueden conectar APIs del navegador mató el impulso de Elm, salvo para proyectos de juguete.
  Ahora parece más un sandbox para que Evan juegue con ideas de compiladores que algo para producción.

  • No creo que eso sea exacto. La app en Elm que mantengo está completamente localizada, y creo que la accesibilidad también está bastante bien.
    La localización la manejamos con un gran record por idioma, que pasamos a cada parte de la app que usa cadenas. Para plurales o casos especiales de cada idioma, se pueden poner funciones simples dentro del record, lo cual es muy práctico.
    La accesibilidad la logramos combinando buen HTML, ports y, para casos complejos como un typeahead de autocompletado, web components.
  • Solo dejen que lo construya. La gente que realmente sabe lo reconocerá cuando esté listo, y a quienes se dejan llevar por las modas no hay forma de rescatarlos.
  • Por un lado, me alegra ver que Evan está bien. Tiene ideas bastante buenas sobre el desarrollo de lenguajes, y Elm inspiró muchos proyectos muy interesantes.
    Por otro lado, pasar 7 años sin nada, sacar una pequeña mejora de rendimiento del compilador y llamarla “el camino hacia 1.0” se siente raro. Sin mala intención, pero ¿para qué? Ya estaba muerto, el duelo terminó y todos se fueron hace mucho.
    No creo que a mucha gente le importe hasta que salga una versión realmente sorprendente.

• Parece que Evan está señalando algo, pero todos están mirando solo el dedo. Creo que en realidad esto no va tanto de Elm en sí, sino de preparar Acadia.
  En su charla Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8 mostró un poco de lo que ha estado trabajando durante los últimos 7 años. Es un lenguaje de consultas que aplica ideas funcionales.
  Señala los límites donde la información de tipos suele romperse en las apps web: entre el lenguaje y el almacenamiento, y entre el almacenamiento y el transporte.
  ¿Qué se obtiene si se puede preservar la información de tipos a través de esos límites? Una de las respuestas que dio es migraciones más fáciles. En vez de escribir SQL a mano, se podría manejar mediante diferencias de tipos.
  Así que creo que la pregunta correcta es si, al ver los cambios que entran en Elm, podemos inferir cómo será Acadia. ¿Qué aportará la compilación incremental a un lenguaje de consultas?

  • Pensando en la historia de Elm, ¿por qué deberíamos creer que Arcadia no terminará igual?
    Por muy buenas que sean las ideas, si Arcadia no tiene un modelo de desarrollo centrado en la comunidad y más orientado al futuro, nadie lo adoptará. En el mejor de los casos será “el proyecto que inspiró a XYZ”.
    Evan puede pensar que esto es la próxima gran cosa, y quizá tenga razón, pero no sé si el mundo después de Elm estará dispuesto a escucharlo lo suficiente.

• ¿Revirtieron aquello de que ciertas funciones del lenguaje solo podían ser usadas por el equipo de Elm? Eso parecía una decisión capaz de matar el lenguaje.

• ¿Es correcto pensar que Elm perdió mucho impulso? Ya casi no se discute ni siquiera en HN, y me pregunto si esa es una de las razones de los grandes intervalos entre versiones y noticias.
  Viendo los intervalos entre versiones, la 0.19.2, “Faster builds, and the Road to Elm 1.0”, es de julio de 2026, y la 0.19.1, “Friendly syntax hints, faster builds”, es de octubre de 2019.

[GN⁺]

Opiniones en Lobste.rs

• ¡Wow! Elm 0.19.1 salió el 21 de octubre de 2019, así que ya pasaron casi 7 años, y además esa había sido la última noticia pública sobre el desarrollo de Elm
  Da bastante gusto ver novedades del proyecto

  • Me emociona mucho que Evan esté planeando un lanzamiento v1
  • Yo también venía a decir esto
    Usé Elm en un proyecto personal y la pasé muy bien, pero desde afuera la comunidad se veía algo tranquila. Es una noticia muy emocionante

• Elm hizo que el desarrollo web fuera divertido
  Tengo ganas de ver qué traerá la 1.0

• Es una sorpresa realmente agradable
  Siempre me gustó la estabilidad de Elm, y parece que la 1.0 tampoco traerá cambios radicales, algo que personalmente veo como un buen rumbo

  • El cambio incompatible descrito parece que podría tener un impacto bastante grande
    Si == y otros ya no aceptan cualquier tipo, habrá bastante código Elm que modificar. Me da curiosidad cómo será el proceso de actualización

• Me alegra ver una actualización de Elm
  Es un poco inusual que un lenguaje de programación pase años sin ninguna actualización. Entiendo las razones, pero la percepción pública tiene sus rarezas

  • Sí, sobre todo en el frontend, donde todo se mueve a una velocidad de locos

• Me gusta esta noticia
  De vez en cuando vuelvo a mirar Elm como una buena pausa de la locura del desarrollo frontend moderno

• Tuve la oportunidad de ver la charla de Evan en ZuriHac 2026, y me sorprendió mucho que insinuara que venía un nuevo lanzamiento de Elm
  Espero que el video se publique pronto, pero parecía haber entendido que una estrategia orientada a la estabilidad no encaja bien con la obsesión de esta industria por avanzar rápido. Según lo entendí, Elm podría avanzar en etapas más pequeñas y rápidas. Me entusiasma, y esa charla hizo que extrañara mucho Elm

• Me da curiosidad cómo manejará Elm funciones más visibles como tipos equatable y hashable
  Una de las decisiones de diseño polémicas del lenguaje es evitar funcionalidades más potentes del sistema de tipos al estilo Haskell, como las type classes. Personalmente, siempre me resultó incómodo que ni siquiera los tipos personalizados con un orden natural y bien definido se puedan usar como claves de diccionarios. Aun así, en general es una buena noticia que el trabajo en Elm continúe

  • Creo que no conviene esperar demasiado funcionalidades al estilo type classes
    Por la forma en que está redactado el post del blog, imagino que será algo como agregar algunas variables de tipo restringidas nuevas además de las variables de tipo restringidas existentes, es decir, number, appendable, comparable y compappend