El lenguaje Mojo (de Modular, ahora Qualcomm) ya es de código abierto
Mojo, un nuevo lenguaje de programación de sistemas creado por Chris Lattner, creador de LLVM y Swift, y ahora propiedad de Qualcomm, ha sido completamente liberado como código abierto bajo Apache 2.0 tras años de disponibilidad parcial. Los comentaristas analizan su promesa como un lenguaje similar a Python, basado en MLIR, para cómputo heterogéneo de alto rendimiento en CPUs, GPUs y aceleradores de IA, frente a preocupaciones sobre la tardía apertura del código, una gobernanza a largo plazo poco clara y si puede construir un ecosistema real frente a incumbentes como Rust, C++, CUDA y Triton. Muchos ven motivos estratégicos en la movida de Qualcomm —especialmente como una jugada anti-NVIDIA— mientras que los desarrolladores individuales están divididos entre el entusiasmo por experimentar y el escepticismo de que Mojo logre una tracción duradera.
Alcance y propuesta de valor de Mojo
- Posicionado como un lenguaje moderno de sistemas con sintaxis similar a Python, sólido soporte SIMD, características en tiempo de compilación y un enfoque en cómputo heterogéneo (CPUs, GPUs, aceleradores).
- Principal argumento de venta: un solo lenguaje y compilador dirigido a GPUs NVIDIA/AMD/Apple, TPUs, Trainium y CPUs sin pilas separadas de CUDA/ROCm/Metal.
- Los usuarios informan que pueden obtener un rendimiento cercano al de C++/Rust en CPU y luego trasladar cargas de trabajo a GPU con más facilidad y ver grandes aceleraciones.
- Algunos lo ven como una posible alternativa tipada estáticamente a Python para tareas numéricas y de sistemas; otros dicen que eso aún no justifica elegirlo por encima de Rust o Zig.
Rendimiento, diseño y hoja de ruta
- Algunas críticas a los benchmarks de rendimiento actuales: ciertos ejemplos de GEMM supuestamente “hacen trampa” al omitir trabajo, descritos como “vibe-coded”.
- Se plantea la pregunta: ¿por qué invertir en un compilador nuevo cuando puedes autoajustar kernels de Triton/CUDA?
- Se señalan como claves faltantes o inmaduras: soporte async, tipos de datos algebraicos + pattern matching, un mejor sistema de traits y uniones etiquetadas más ergonómicas.
- Mojo está estrechamente integrado con MLIR, que algunos ven como una base poderosa para optimizaciones a nivel de biblioteca y una experiencia “MLIR++”.
Relación con Python y ecosistema
- El marketing inicial como un superconjunto de Python creó expectativas; la realidad actual es más la de un “lenguaje Pythonic” que la de Python totalmente compatible.
- A algunos les interesa más ahora que no es estrictamente un subconjunto de Python; otros ven la falta de interoperabilidad completa con Python como un bloqueo para una adopción más amplia.
- Interés en la transpilación estática de Python → Mojo y en hacer que el pattern matching se parezca más a Rust (basado en expresiones) que a Python.
Código abierto, gobernanza y Qualcomm
- Muchos dicen que mantener el compilador cerrado perjudicó significativamente la adopción; el código abierto bajo Apache 2.0 es ampliamente bienvenido.
- Hay desacuerdo sobre la razón para retrasar el código abierto:
- Un lado: el retraso evitó cambios tempranos de diseño, roturas para la comunidad y estrés “al estilo Swift”.
- El otro lado: ve esto como una justificación débil o posterior a los hechos; argumenta que la verdadera razón fue la baja prioridad dada a la apertura.
- Algunos temen que la adquisición por parte de Qualcomm signifique que Mojo podría estancarse o ser únicamente una herramienta estratégica “anti-NVIDIA”; otros dicen que el código abierto ya estaba previsto antes de la adquisición y señalan la mejora de la postura de Qualcomm respecto al código abierto.
Adopción, LLMs y panorama de lenguajes
- Debate sobre si vale la pena aprender ecosistemas pequeños; una postura dice que los lenguajes sin comunidades no sirven para nada, otra señala que los LLMs ahora pueden escribir lenguajes de nicho, reduciendo esa barrera.
- Comparaciones con Rust y C++: el modelo de memoria de Mojo se describe como similar al de Rust, pero con una superficie más procedimental/Pythonic; algunos lo ven como “lo que C++ podría haber sido”, otros dicen que Rust ya cumple ese papel.