Elixir siempre ha sido un lenguaje dinámico: no hay anotaciones de tipo obligatorias, el compilador no verifica tipos antes de ejecutar. Eso era verdad hasta el 3 de junio de 2026, cuando el equipo de José Valim publicó Elixir v1.20 y anunció algo que llevaba años en construcción: el compilador ahora infiere tipos en todo el código y detecta bugs garantizados en tiempo de compilación, sin que el desarrollador escriba una sola anotación.
El proyecto lleva cuatro versiones madurando. En 1.17 llegaron los primeros tipos de conjunto para funciones de la librería estándar. En 1.18 y 1.19 el sistema aprendió a propagar esa información a través de guardias y cláusulas. Con 1.20 se cierra la primera fase: inferencia completa de todos los constructos del lenguaje.
Qué significa «gradualmente tipado» en la práctica
No es lo mismo que tipado estático. El sistema de Elixir no obliga a que todo sea verificable ni rechaza código que no puede tipificar: simplifica en el tipo dynamic() cuando no tiene información suficiente. La diferencia con otros sistemas graduales está en cómo se comporta ese dynamic().
En TypeScript o Python, el tipo any/dynamic básicamente apaga el análisis: todo es compatible con any. En Elixir, dynamic() funciona como un rango que se estrecha. Si tienes una variable de tipo dynamic(integer() or binary()) y la pasas al operador /, no hay error porque un integer encaja. Pero si la pasas a Map.fetch!/2, el compilador avisa: ningún miembro del rango es un mapa, eso va a fallar en runtime si se ejecuta.
El resultado práctico es que el sistema solo reporta lo que está garantizado que falla, no advertencias conservadoras. La tasa de falsos positivos es deliberadamente baja para no molestar a proyectos existentes.
Occurrence typing: tipos que se refinan en cada rama
Una de las novedades más útiles de 1.20 es el soporte completo de occurrence typing en case, cond y with. Elixir usa la información de cláusulas anteriores para refinar las siguientes.
Ejemplo concreto: si la primera cláusula de un case hace match sobre nil, en las cláusulas siguientes el compilador sabe que la variable ya no puede ser nil. No hace falta que el desarrollador repita esa lógica: el sistema la deduce solo. Esto encaja bien con el estilo de pattern matching que ya usan la mayoría de proyectos Elixir.
Tipado de mapas con dominios de clave
Los mapas en Elixir son muy flexibles y eso los hace difíciles de tipar. En 1.20 el sistema ya puede rastrear todos los dominios posibles de clave de un mapa y detectar accesos a claves que no pueden existir según el flujo del programa. Para structs y mapas con forma fija esto es especialmente útil.
Compilación más rápida en multicore
Además del sistema de tipos, 1.20 mejora el paralelismo del compilador en máquinas con varios núcleos. Los benchmarks internos lo sitúan como el compilador más rápido entre los lenguajes de la BEAM (Elixir, Erlang, Gleam). Para proyectos grandes, el tiempo de compilación baja de forma apreciable.
También llega una nueva opción :module_definition: :interpreted pensada para proyectos con muchos módulos que hacen uso intensivo de macros en tiempo de compilación.
Qué queda por hacer antes de las anotaciones opcionales
El equipo es claro sobre lo que falta. Antes de introducir type signatures opcionales (la siguiente fase del roadmap), el sistema necesita resolver tipos recursivos eficientes, tipos paramétricos y enumerables de pares clave-valor en mapas. Eso es trabajo de los próximos 12-15 meses según el post de enero de 2026.
El ritmo es deliberado: primero demostrar que el sistema funciona bien sin anotaciones, luego añadir la capa opcional para quienes quieran ser más explícitos.
Requisitos y migración
Elixir 1.20 requiere Erlang/OTP 27 o superior. Si tu proyecto usa OTP 26 o anterior, tendrás que actualizar antes de migrar. La compatibilidad con OTP 29 (la versión más reciente) está confirmada.
La mayoría de proyectos existentes no necesitan cambios: el sistema de tipos es informativo, no bloquea la compilación salvo que el código tenga bugs verificados. Lo más probable es que aparezcan algunos avisos nuevos en código que antes pasaba sin problemas, que son bugs reales esperando ser encontrados.
Si aún no has explorado el ecosistema BEAM, los artículos sobre supervisores en OTP y Nx y Livebook para machine learning en Elixir dan buena perspectiva de hasta dónde puede llevarte el lenguaje. Y si quieres entender cómo Elixir convive con Gleam, el artículo sobre Gleam vs Elixir en el ecosistema BEAM cubre exactamente eso.
Imagen: Pexels / Markus Spiske