Modular ha publicado Mojo 1.0 dentro de su versión 26.5, y con ella el compromiso de que los cambios durante la rama 1.x serán principalmente aditivos. Es la señal que la comunidad llevaba dos años esperando: hasta ahora, cada versión de Mojo rompía código y eso hacía inviable construir nada encima. Detrás hay casi 200 colaboradores, más de 1.100 pull requests y más de 200.000 líneas de código cambiadas.
Puntos clave
- Mojo 1.0 liberado el 11 de agosto de 2026, con compromiso de estabilidad al estilo de lenguajes maduros como C++.
- Casi 200 colaboradores externos, más de 1.100 pull requests y más de 200.000 líneas modificadas.
- Modular se compromete a abrir el código del compilador y del toolchain de Mojo durante 2026.
- ModCon, su conferencia, el 18 de agosto de 2026.
Qué significa el 1.0
Modular es explícita en el matiz, y hay que reproducirlo tal cual: seguirá habiendo cambios que rompan compatibilidad, pero se gestionarán con cuidado, siguiendo los estándares de cómo evolucionan los lenguajes maduros.
Eso es lo que separa un lenguaje experimental de uno con el que se puede trabajar. Hasta ahora, una librería de la comunidad escrita en Mojo tenía fecha de caducidad: la siguiente versión del lenguaje la iba a romper. Con esa incertidumbre encima, nadie invierte meses en construir el ecosistema.
El compromiso de abrir el compilador y el toolchain durante 2026 es la otra pata. Mojo se presentó como abierto y arrastra desde el principio la crítica de que las piezas importantes eran propietarias.
Qué trae la 26.5
Del lado del lenguaje, sintaxis de lambda al estilo Python para closures, un servidor LSP más estable para los editores y diagnósticos de seguridad de memoria que detectan invalidación de referencias. Ese último punto es donde Mojo pelea: quiere el rendimiento de un lenguaje de sistemas con controles que impidan los fallos clásicos de memoria.
Del lado de los modelos, soporte para las familias GLM-5.2 y Nemotron-H, y compatibilidad de Kimi 2.5 con Module V3.
La instalación de MAX, su plataforma de inferencia, se simplifica con `max["serve"]`, `max["benchmark"]` o `max["all"]`, en lugar del proceso anterior.
También han actualizado las Mojo AI Skills, las instrucciones que hacen que un asistente de código sepa crear proyectos y programar GPUs en Mojo. Ese detalle es más significativo de lo que parece: un lenguaje nuevo tiene el problema de que los modelos de IA no lo conocen bien porque hay poco código público suyo con el que entrenar. Empaquetar el conocimiento en skills es la forma barata de esquivar eso.
Por qué importa
Modular vende una idea concreta: que hoy hay que escribir Python para prototipar y luego C++ o CUDA para que vaya rápido en GPU, y que Mojo hace las dos cosas. Si eso se sostiene, el equipo que optimiza inferencia deja de necesitar dos perfiles distintos.
El anuncio no trae comparativas de rendimiento contra CUDA ni contra Python, y eso hay que decirlo. La versión 1.0 va de estabilidad, no de velocidad.
Tampoco especifica qué GPUs y qué arquitecturas de CPU soporta en esta versión, otro dato que en un anuncio de lenguaje de sistemas se echa de menos. Y el compromiso de abrir el compilador sigue siendo eso, un compromiso con fecha de año, sin día. ModCon, el 18 de agosto, es el sitio donde deberían aterrizar esos detalles.
Para una empresa española, esto es infraestructura, no herramienta de uso diario. Solo aplica si tenéis a alguien optimizando inferencia sobre GPU propia, y ese es un perfil raro por debajo de cierto tamaño. La lectura útil es indirecta: el ecosistema de servir modelos en hardware propio se está profesionalizando. Cada pieza que madura ahí baja el coste de no depender de una API de pago por token.
Relacionado
