- Chris Lattner es un desarrollador clave de LLVM y del lenguaje Swift, y está desarrollando el nuevo lenguaje Mojo para aprovechar al máximo el rendimiento del hardware moderno de ML
- Mojo busca diseñarse como un lenguaje que ofrezca tanto facilidad de uso como control detallado del hardware, y permite manejar eficientemente esos detalles mediante metaprogramación con seguridad de tipos
- El contexto clave es construir una plataforma de cómputo unificada que resuelva la fragmentación del ecosistema de aceleradores de IA como GPU, TPU y ASIC, y reduzca la dependencia de proveedores específicos
- Debido a los problemas de compatibilidad y complejidad en los stacks de software actuales para GPU (CUDA, ROCm, XLA, etc.), es indispensable desarrollar un lenguaje de próxima generación con alto rendimiento y portabilidad
- Modular impulsa un modelo de negocio enfocado en ofrecer Mojo gratis y en resolver problemas reales mediante soporte de hardware unificado y servicios empresariales
Introducción a Chris Lattner y su carrera
- Chris Lattner ha liderado varios proyectos fundamentales del mundo de la computación, como LLVM, Clang, MLIR, Swift y Mojo
- Ha trabajado en distintas organizaciones como Apple, Tesla, Google, SiFive y Modular, acumulando una amplia experiencia práctica en compiladores y diseño de lenguajes de programación
- Comenzó en entornos de PC y con lenguajes simples como BASIC, y fue a través de los juegos y los gráficos que desarrolló interés por exprimir al máximo el rendimiento del hardware
- Durante la universidad, por influencia casual de un profesor especializado en compiladores, descubrió el atractivo de los sistemas y de la arquitectura de software a gran escala
Entre compiladores y diseño de lenguajes
- Chris Lattner ha trabajado tanto en ingeniería de compiladores como en diseño de lenguajes, logrando grandes avances en la intersección de ambas áreas
- Por ejemplo, LLVM funciona como un lenguaje intermedio utilizable por muchos lenguajes distintos, y no solo ha servido para implementaciones en C++, sino también para casos de uso muy amplios como Rust o Julia
- El desarrollo de Swift también surgió como un intento de superar las limitaciones y el desgaste asociados con las implementaciones existentes en C++, destacando la necesidad de funciones prácticas como el pattern matching
- En innovación de lenguajes de programación, prefiere un enfoque basado en resolver problemas reales y ofrecer utilidad, más que en la teoría matemática
Teoría de lenguajes de programación y practicidad
- Chris prioriza una forma de pensar centrada en la resolución de problemas más que en el rigor matemático, y en los artículos académicos de PL le interesan más los ejemplos prácticos y los casos de uso que la teoría en sí
- Reconoce que las funciones de lenguaje con bases matemáticas sólidas tienen ventajas en consistencia y composabilidad, pero que la adopción real suele estar impulsada por la utilidad visible en el uso cotidiano
- Menciona que, al diseñar nuevos lenguajes o tecnologías, es importante reducir al máximo el "grano de arena" de la complejidad, buscando simplicidad y escalabilidad en el diseño
Problemas estructurales del ecosistema de hardware para IA
- La infraestructura tradicional de compiladores (LLVM) estaba centrada en CPU, pero la IA y el aprendizaje automático requieren diverso hardware especializado como GPU, TPU, ASIC y FPGA
- Cada proveedor desarrolla su propio stack de software (CUDA, ROCm, XLA, etc.), lo que provoca falta de compatibilidad y fragmentación del ecosistema
- El software de ML (por ejemplo, PyTorch) necesita optimizaciones separadas para cada proveedor de hardware, lo que vuelve muy difícil su mantenimiento y expansión
- Como cada hardware tiene stacks, lenguajes y ecosistemas de herramientas distintos, la productividad y la portabilidad del software se ven ampliamente afectadas desde la perspectiva del desarrollador
El papel de Modular y Mojo
- El equipo de Modular está enfocado en construir una plataforma de software general e integrada para resolver estos problemas
- Mojo está diseñado no solo para sacar provecho del rendimiento de arquitecturas modernas de GPU como los tensor cores, sino también para permitir la escritura de kernels portables para distintos tipos de hardware
- Mediante una estructura multicapa que incluye Mojo, MAX (por ejemplo, serving de LLM de alto rendimiento) y Mammoth (gestión de clústeres/Kubernetes), buscan ofrecer una infraestructura de IA integrada
Por qué hace falta Mojo y decisiones de diseño del lenguaje
- Con los lenguajes existentes no se pueden satisfacer al mismo tiempo dos necesidades: la portabilidad de kernels de ML de alto rendimiento y la optimización específica para cada proveedor
- Mojo debe poder responder dinámicamente a hardware que cambia con gran rapidez, incluyendo detalles de bajo nivel del hardware, como diversos tipos de datos (por ejemplo, floating point de 8 bits) y tensor cores
- Su modelo de metaprogramación con seguridad de tipos transforma el control complejo del hardware en algo más eficiente y más fácil de compartir
Cambios en el hardware y en el diseño de kernels
- Los CPU de los centros de datos modernos han escalado a muchos núcleos, mientras que los GPU han evolucionado rápidamente con diseños especializados en procesamiento paralelo, como la estructura SM (Streaming Multiprocessor) y los warps (ejecución de 32 hilos)
- Con la incorporación en hardware de unidades de cómputo especializadas para IA como los tensor cores, se vuelve necesario un paradigma de programación de hardware completamente distinto del CUDA tradicional
- Incluso dentro del mismo proveedor, los cambios de compatibilidad entre generaciones de arquitectura son frecuentes (por ejemplo, entre Nvidia Volta, Hopper y Blackwell), y los stacks de software no logran seguir ese ritmo
Modelo de negocio y estrategia de ecosistema abierto
- Modular no se enfoca en vender el lenguaje en sí, sino que publica Mojo de forma gratuita
- Su modelo principal de ingresos se basa en la oferta de plataforma y servicios para empresas, junto con gestión de hardware unificada
- Con esto busca construir un ecosistema compartido sin vendor lock-in, persiguiendo al mismo tiempo soporte para diversos tipos de hardware y una gestión eficiente de la infraestructura
Conclusión
- El proyecto Mojo de Chris Lattner y Modular representa la construcción de un nuevo lenguaje de programación y una nueva plataforma para afrontar la creciente complejidad del aprendizaje automático, la innovación en hardware de IA y la fragmentación del ecosistema
- Mediante un diseño de lenguaje innovador y la expansión de un ecosistema abierto, la estrategia apunta a contribuir a la democratización del ecosistema de IA y al aumento de la productividad
1 comentarios
Opinión de Hacker News
Quiero agradecer a todos los que mostraron interés en Mojo y en el pódcast. Si quieren saber más sobre Mojo, pueden revisar las preguntas frecuentes en el FAQ (incluye una respuesta a “por qué no simplemente hacer mejor a Julia”). La documentación también está disponible aquí y el código open source ya se publicó con cientos de miles de líneas. La comunidad de Mojo también es realmente excelente, así que sería genial que se sumaran al foro de Discourse o al chat de Discord - comentario de Chris Lattner
Soy fan. He visto varias presentaciones sobre Mojo y, aunque dicen que aprovecha tecnología de compiladores de punta, nunca he escuchado ejemplos concretos. Aunque uno no sea desarrollador de compiladores y solo entienda como un 20%, me gustaría sentir de verdad qué tiene de especial esa tecnología avanzada, así que estaría genial un post de blog realmente profundo y técnico
En el FAQ preguntan "¿Sigue disponible Mojo Playground?" y te mandan a ese playground, pero ahí mismo dice que “Playground se eliminará en la próxima versión 25.6”. Que la respuesta del FAQ sobre “si esto está disponible” te envíe a una función que está a punto de desaparecer parece perder el punto principal. En la práctica, la respuesta parece ser “no por mucho tiempo”
Chris, qué gusto verte por aquí. Hace tiempo incluso invertí por Light Table y me preguntaba si había alguna actualización. (No lo pregunto en serio, aunque Mojo sí se ve interesante). Me pregunto qué tan sostenible es este tipo de proyecto a largo plazo y si hay fundamentos confiables para tenerle fe
Python domina el mundo de ML porque las aplicaciones modernas de ML no son simples scripts de cálculo, sino que requieren funciones muy amplias y un ecosistema robusto. Preprocesamiento de datos de todo tipo (ETL), manejo de datos en formatos diversos, procesamiento distribuido en clústeres de cómputo de alto rendimiento, visualización e integración con GUI/DB: no hay otro lenguaje aparte de Python que abarque todo eso. Las operaciones numéricas son muy rápidas porque internamente NumPy, PyTorch, JAX y otros usan C/C++/FORTRAN, y además es fácil implementar por separado en C/C++ solo el código donde el rendimiento sí importa. El sistema de FFI con C/C++ de Python también es bastante práctico comparado con otros lenguajes. Todo eso tiene muchas más ventajas que volver a implementar todo el ecosistema en otro lenguaje como Julia
El ecosistema de Python no tiene rival, pero la combinación Elixir/Nx ya hace gran parte de lo que Mojo promete. Con EXLA ya se puede compilar para GPU/TPU, usar Explorer/Polars para dataframes e incluso incrustar librerías de Python con Pythonx. La diferencia es que Elixir fue pensado desde el inicio para construir sistemas distribuidos, así que BEAM/OTP puede manejar enormes volúmenes de solicitudes concurrentes y coordinación entre nodos con GPU. Si uno fuera a construir un servicio real de ML, tener Phoenix, LiveView y Nx como un solo stack sólido con tolerancia extrema a fallas y escalabilidad podría importar más que una pequeña mejora en rendimiento de hardware
Yo tengo una postura algo distinta en la parte de inferencia. Es fácil meterse directo a tocar los kernels de CUDA, y el CUTLASS 3 más reciente o el C++ moderno han mejorado bastante la experiencia. Encima de eso hay una capa delgada de Torch, pero esa parte es difícil de compilar y solo agrega complejidad por temas como el conteo de referencias y otros problemas. La implementación realmente importante está en los kernels de abajo, y pronto pienso quitar esa “cubierta de torch” y usarlo con una conexión más clara hacia un programa limpio en C++
Ese problema es preocuparse por los kernels de GPU, y esos kernels de entrada no se escriben en Python. Python es el lenguaje de “pegamento” para ML. Estoy de acuerdo con la idea de que “solo Python ofrece todas las funciones”, aunque sí da un poco de pena que el ecosistema haya crecido alrededor de Python y no de un lenguaje mejor
Que Python se volviera el lenguaje representativo de ML fue un “círculo virtuoso”. El ecosistema creció porque ya había sido elegido, pero la razón de esa elección inicial requiere otra explicación. Ahora es tan grande que parece imposible de superar, pero eso no basta como argumento para explicar por qué Python fue la opción desde el principio
Irónicamente, Python es el peor lenguaje para todas las tareas mencionadas. El empaquetado y los binarios (
wheel) son un dolor, y siempre hay algo que se rompe. Está bien para scripts aislados, pero si Python hubiera sido diseñado con la meta de convertirse en el lenguaje principal de ML, nadie habría querido que terminara asíMe impactó escuchar el episodio. Me sorprendió que incluso en septiembre de 2025 el soporte para clases siga siendo una meta de mediano plazo. Antes se promocionaba mucho a Mojo como “superconjunto de Python”, pero al ritmo actual eso parece más una meta ideal que algo realista
En realidad, nunca fue una meta ser un “superconjunto de Python”. Era más bien un eslogan para atraer atención, que se enfatizó al principio y luego se fue retirando discretamente
Tal vez no sea por velocidad, sino porque simplemente no les gusta la POO en sí
Siempre fue una meta de largo plazo
Tal vez sea una pregunta muy típica, pero me pregunto: ¿por qué no Lisp? Si asumimos que en el futuro el código de ML terminará siendo escrito por máquinas (o por sistemas automáticos de conversión basados en lenguaje natural), las S-Expressions de Lisp son prácticamente un AST, así que es el lenguaje más natural para una máquina. Además, normalmente ya tiene un entorno REPL completo, así que también parecería encajar muy bien como reemplazo de Python
Yann LeCun y otros hicieron Lush, un Lisp para ML. Era de lo mejor en los 2000 y no hubo una alternativa real hasta que llegaron Python (Theano) o Lua (Torch). Ojalá Lisp volviera a recibir atención hoy en día. Python tiene librerías excelentes, pero al lenguaje en sí todavía le faltan varias mejoras
Los LLM (modelos de lenguaje grandes) todavía no son buenos contando paréntesis ;)
Como Lisp ya tuvo la experiencia de ser dejado de lado durante un boom anterior de IA, muchos desarrolladores todavía usan solo Emacs + SBCL. En realidad también existen otras implementaciones avanzadas de Lisp como LispWorks, Allegro o Clozure, pero mucha gente nunca las ha probado
Para empezar, la licencia de Mojo no me gusta nada
Yo también lo revisé: la licencia de Mojo distingue entre uso en CPU o Nvidia y otros “aceleradores” (TPU, AMD, etc.), y aclara que para uso comercial hace falta una licencia aparte ver blog
Desde mi punto de vista, si Mojo es un lenguaje controlado de forma absoluta por una empresa específica, no hay ninguna razón para adoptarlo en un negocio. Ya hubo muchas empresas que tuvieron problemas con cambios en la licencia de Java. Montar un negocio sobre Mojo en lugar de Python es un riesgo excesivo
Al ver el FAQ de Mojo, parece que en sentido estricto sí apuntan a ser un superconjunto de Python, pero en la hoja de ruta dicen “ofrece código Python y familiaridad, pero no puede ser un superconjunto completo”, así que solo genera más confusión. Si la compatibilidad con Python no es la meta, no entiendo por qué siguen mencionando tanto a Python. Además, me pregunto si de verdad existe eso de usar un emoji como extensión de archivo
Hasta donde yo sé, Mojo solo busca una sintaxis estilo Python e interoperabilidad con Python. Más allá de eso, venderlo como algo similar a Python es sobre todo marketing
Sobre la extensión con emoji: sí, es real. Es U+2615 (el emoji de café)
Quiero entender en qué supera Mojo a Julia, porque aunque Julia tiene limitaciones de interfaz y ecosistema, también se integra bastante bien con Python, así que no siento que Mojo sea claramente mejor
En particular, Julia ya tiene un ecosistema GPU bastante bien armado con JuliaGPU y Reactant ver Reactant.jl
La compatibilidad con Python quizá sea mejor en Mojo, pero en la práctica en Julia también es bastante estable llamar librerías de Python mediante PythonCall.jl. Los frameworks de ML (Lux.jl, Flux.jl) también funcionan bien dentro de Julia. No parece que Mojo todavía tenga frameworks nativos de ML a ese nivel
Mojo parece apuntar mucho más a sentirse como un lenguaje de bajo nivel, con más control y más solidez. Julia, en cambio, no es predecible ni en significado ni en rendimiento, así que no sirve como base para software crítico, mientras que Mojo tendría ventaja en ese punto
Intenté crear módulos de Python con Julia, pero sentí que todavía faltaba soporte. En Mojo eso sí parece ser una función central
Julia todavía está algo corta en compilar código a binarios nativos completos (como Rust o C++)
El hecho de que Mojo no haya generado una atención enorme y que PyTorch siga usándose tanto podría ser una señal de que el tema de la licencia pesa más de lo esperado
Parece que Mojo fue demasiado optimista al definir su espacio. Incluso Julia está aumentando gradualmente su uso comercial y tiene buen soporte de GPU. Aunque el compilador JIT de Python sea limitado, Nvidia, Intel y otros están optimizando bastante la programación GPGPU con DSLs en Python, al punto de acercarse a niveles tipo C++ dentro de Python. Al final, a Mojo le falta una diferencia clara
Desde la perspectiva de sistemas, impresiona el intento de Chris y su equipo de arreglar de una vez los problemas de FFI entre múltiples lenguajes usando Mojo. Aun así, hasta que no sea open source, ni siquiera se puede empezar a hablar de invertir
Todavía no está listo para usarse como lenguaje de propósito general. Modular quiso aplicar la API de Mojo al motor MAX, pero el lenguaje cambia tan rápido que dejaron de invertir en ello. Según la hoja de ruta, se espera una adopción más seria solo después de completar la fase 1
Ni siquiera sé si de verdad se puede llamar “público”. Hasta hace poco no se había hecho open source, y daba cosa depender de software comercial privativo
Al principio del artículo dicen que se pueden usar “kernels de vanguardia”. Al final, parece que Mojo quiere competir con C++ en el desarrollo de kernels. En PyTorch o Julia normalmente uno no escribe kernels directamente, sino que trabaja más en alto nivel
Hay episodios del pódcast de Lex Fridman en los que participó Chris Lattner:
El intento de Mojo en sí es audaz e interesante, pero si es un lenguaje cerrado como Matlab, para mí y para mucha gente eso es un defecto descalificante serio