Mojo 1.0 beta

(mojolang.org)

3 puntos por GN⁺ 7 시간 전 | 1 comentarios | Compartir por WhatsApp

Mojo se presenta como un lenguaje que “se escribe como Python y se ejecuta como C++”, y actualmente ofrece la versión estable 1.0.0b1 (May 7)
Está diseñado como un lenguaje estático y de alto rendimiento para sistemas de IA modernos, con el objetivo de escribir código rápido sobre distintos tipos de hardware, desde CPU hasta GPU, sin depender de un proveedor específico
Soporta de forma nativa la interoperabilidad con Python, por lo que permite mover a Mojo solo los cuellos de botella de rendimiento sin reescribir todo el código existente, y admite tanto el import de código Mojo desde Python como el import de bibliotecas de Python dentro de Mojo
Permite escribir kernels de GPU en el mismo lenguaje, y busca ofrecer optimizaciones específicas por hardware y abstracciones sin costo mediante metaprogramación en tiempo de compilación usando el mismo lenguaje que el código de ejecución
La biblioteca estándar de Mojo está completamente open source en GitHub y recibe contribuciones, mientras que el compilador de Mojo tiene previsto abrirse como open source en 2026

Versiones y recursos para empezar

La versión estable actual es 1.0.0b1 (May 7), y la nightly más reciente es May 9
Mojo se inspira en la sintaxis intuitiva de Python, la seguridad de memoria de Rust y la metaprogramación en tiempo de compilación potente e intuitiva de Zig
Como lenguaje estático compilado, también es adecuado para programación orientada a agentes
En lugar de obligar a elegir entre productividad o rendimiento, busca ofrecer ambas, permitiendo empezar con patrones de programación simples y familiares y agregar complejidad cuando haga falta
Como rutas de inicio ofrece Install Now, Quickstart, Releases, Roadmap, GitHub
Para ver una página en Markdown se puede agregar .md al URL, y el índice completo de la documentación de Mojo está disponible en llms.txt

GPU e interoperabilidad con Python

Programación para GPU

Mojo busca hacer accesible la programación para GPU sin bibliotecas específicas de cada proveedor ni código de compilación separado
Permite escribir kernels de GPU de alto rendimiento en el mismo lenguaje usado para CPU

El kernel de ejemplo vector_add recibe TileTensor y realiza result[i] = a[i] + b[i] usando global_idx.x como base

def vector_add(  
    a: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    b: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    result: TileTensor[  
        mut=True, float_dtype, type_of(layout), element_size=1, ...  
    ],  
):  
    var i = global_idx.x  
    if i &lt; layout.size():  
        result[i] = a[i] + b[i]

Interoperabilidad con Python
- Mojo es interoperable de forma nativa con Python, lo que permite eliminar cuellos de botella de rendimiento sin reescribir por completo el código existente
- Puede empezar desde una sola función y escalar moviendo a Mojo el código crítico para el rendimiento según sea necesario
- El código de Mojo puede importarse de forma natural en Python y empaquetarse junto con paquetes para distribución
- A la inversa, dentro del código Mojo también se pueden importar bibliotecas del ecosistema de Python
- La función de ejemplo mojo_square_array obtiene un puntero desde ctypes.data de PythonObject, calcula en tiempo de compilación el ancho SIMD y eleva al cuadrado los elementos del arreglo
```
# SIMD-vectorized kernel squaring array elements in place.  
def mojo_square_array(array_obj: PythonObject) raises:  
    comptime simd_width = simd_width_of[DType.int64]()  
    ptr = array_obj.ctypes.data.unsafe_get_as_pointer[DType.int64]()  
    def pow[width: Int](i: Int) unified {mut ptr}:  
        elem = ptr.load[width=width](i)  
        ptr.store[width=width](i, elem * elem)  
    vectorize[simd_width](len(array_obj), pow)  
```

Metaprogramación en tiempo de compilación

La metaprogramación de Mojo ofrece un sistema intuitivo que usa el mismo lenguaje que el código de ejecución para maximizar el rendimiento
Mediante compilación condicional permite crear optimizaciones específicas por hardware, garantizar la seguridad de memoria con evaluación en tiempo de compilación y eliminar bifurcaciones costosas en tiempo de ejecución
Su objetivo es ofrecer abstracciones sin costo mientras expresa la intención de manera clara

La implementación de ejemplo de __eq__ obtiene nombres y tipos de campos de una estructura mediante reflexión en tiempo de compilación, comprueba que todos los campos cumplan Equatable y luego realiza la igualdad campo por campo

# Generic struct equality using compile-time reflection.  
@always_inline  
def __eq__(self, other: Self) -&gt; Bool:  
    comptime r = reflect[Self]()  
    comptime names = r.field_names()  
    comptime types = r.field_types()  
    comptime for i in range(names.size):  
        comptime T = types[i]  
        comptime assert conforms_to(T, Equatable), &quot;All fields must be Equatable&quot;  
        if trait_downcast[Equatable](  
            r.field_ref[i](self)  
        ) != trait_downcast[Equatable](r.field_ref[i](other)):  
            return False  
    return True

Hoja de ruta y open source

Mojo comenzó a finales de 2022 y todavía queda mucho por hacer
Phase 0
- Etapa de construcción de la base inicial
- Es la fase de implementación del parser central, tipos de memoria, funciones, estructuras, inicializadores, convenciones de argumentos y otras bases del lenguaje
Phase 1
- Etapa actualmente en curso
- Su objetivo es convertirlo en un lenguaje potente y expresivo para escribir kernels de alto rendimiento en CPU, GPU y ASIC, y permitir que los desarrolladores extiendan Python sin fricciones
Phase 2
- Etapa de programación de aplicaciones de sistema
- Es la fase de expansión para soportar un modelo de seguridad de memoria garantizada y más capacidades de abstracción de las que esperan los desarrolladores de programación de sistemas
Phase 3
- Etapa de programación orientada a objetos dinámica
- Es la fase en la que se agregará más soporte para características dinámicas de Python, como clases, herencia y variables sin tipo, para maximizar la compatibilidad con código Python
- Más detalles están disponibles en Mojo roadmap
- La biblioteca estándar de Mojo está completamente open source en GitHub y recibe contribuciones
- El compilador de Mojo tiene previsto abrirse como open source en 2026
- Aunque la política es abrir como open source todo Mojo, consideran que como el lenguaje aún es muy joven, un grupo cercano de ingenieros con una visión común puede avanzar más rápido que un modelo impulsado por la comunidad
- Como vía de participación se ofrece la developer community

Recursos de aprendizaje y comunidad

Install y Quickstart guide: recursos para empezar con Mojo
Beginner tutorial: aprender Mojo creando Game of Life
GPU puzzles: aprender programación para GPU con Mojo resolviendo acertijos
Intro to Mojo: introducción general a las funciones del lenguaje Mojo
Developer forum: preguntas y actualizaciones relacionadas con Mojo
Events: información sobre eventos, meetups, presentaciones y hackatones
Contributions: guía sobre issues abiertos, contribuciones a la documentación y cómo compartir proyectos

1 comentarios

GN⁺ 7 시간 전

Comentarios en Hacker News

He usado bastante Mojo por diversión durante los últimos 2 años, y de verdad es un lenguaje genial
Tiene un modelo de ownership cercano a Rust, ejecución en tiempo de compilación más potente que Zig, un sistema de tipos rico y soporte SIMD de primera clase
También en rendimiento se ve como un lenguaje de verdad y no solo como otro wrapper simple sobre LLVM. Sigue usando LLVM, pero lo aprovecha de una forma distinta a Rust o Zig
Tengo muchas expectativas por Mojo cuando sea open source a finales de este año
- Estaría bien que explicaras un poco más la parte de “ejecución en tiempo de compilación más potente que Zig”
  Solo con la documentación actual de Mojo cuesta llegar a esa conclusión
Como alguien que trabaja en machine learning y se preocupa por el rendimiento, espero que Mojo tenga éxito. En especial me entusiasma poder mezclar código de GPU y CPU en el mismo lenguaje
Pero me preocupa que los cambios actuales terminen alejando a los desarrolladores de Python. La última vez que lo probé, intenté hacer manipulaciones básicas de strings con var x = 'hello'; print(x[3]) y no funcionó, y tampoco len(x), así que perdí una hora dándole vueltas
Resultó que habían decidido separar más explícitamente las representaciones de bytes y code points, pero la documentación se contradecía con la implementación real
Ojalá llegue a un estado útil para machine learning en general, pero por ahora se siente bastante limitado. Incluso eliminaron algunas funciones base decentes relacionadas con tensores
Por ahora seguiré con JAX y lo revisaré de vez en cuando
- No entiendo por qué todavía no existe un lenguaje que convierta código simple y centrado en cómputo en SIMD / multihilo / multiprocesamiento / código GPU con una sintaxis adicional mínima
  Suena como el tipo de cosa con la que soñaría la gente interesada en compiladores y diseño de lenguajes
  No hace falta que garantice eficiencia en cualquier situación ni que ofrezca rendimiento de punta; con que simplemente exista ya estaría bien
  Entiendo que sí se puede hacer un lenguaje así, pero parece que no ha logrado atraer el interés de quienes podrían construirlo
- Mojo es genial, pero no entiendo por qué siguen aferrados a la compatibilidad con Python. Eso mismo los está frenando
  Casi todas las desventajas que se me vienen a la mente de Kotlin se deben a la compatibilidad con Java. Aquí quizá se podía resolver mejor de forma más explícita, pero el enfoque actual parece condenado al fracaso
- Si no es open source, no tiene mucho sentido. La mayoría de los desarrolladores de Python de todas formas no van a venir
- En este aspecto parece casi como si quisieran reinventar el lenguaje de programación Nim
Dice que “prometieron liberar Mojo como open source en otoño de 2026”
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Estaría bien poder ver el código fuente de un programa de MLIR realmente de vanguardia
Lamentablemente, mientras tanto Nvidia tampoco se quedó quieta, y creó una CUDA de nueva generación llamada CuTile para Python, y pronto también para C++, a través de un stack de compilación parecido basado en MLIR
Aunque no tenga portabilidad, es muy probable que termine usándose mucho más que Mojo solo porque Nvidia la empuja con fuerza, la integra en sus herramientas de desarrollo y funciona junto con el código CUDA existente
Es probable que Tile IR haya sido más una respuesta a la amenaza de Triton que a Mojo. Sobre todo si se mira desde qué tan fácil es escribir kernels de LLM con rendimiento aceptable
- Para no quedarse atrás, Intel y AMD también están haciendo esfuerzos parecidos, y el JIT de CPython por fin se está volviendo realidad tras varios intentos
  También existen intentos como GraalPy y PyPy
  Todos estos esfuerzos funcionan hoy en Windows. Eso importa bastante en entornos donde en la empresa la mayoría de los empleados recibe equipos con Windows y solo los servidores usan distribuciones Linux
  Esto me hace pensar una y otra vez si no terminará como otro Swift for Tensorflow
- Por lo que he hablado con algunos desarrolladores de Tile IR, la motivación principal era ofrecer mejor portabilidad para programar tensor cores que PTX
  Aparte del feedback de clientes, nadie me dijo que fuera una respuesta a otra cosa
- Mucha gente confunde Mojo con solo una sintaxis cómoda para escribir código GPU, y piensa que los frameworks de Python de Nvidia ya cubren eso
  Pero ¿CuTile funcionará también en GPU de AMD o en Apple Silicon? Haga lo que haga Nvidia, la dependencia de proveedor sigue ahí
- Tengo curiosidad por saber qué tanto impacto tendrá CuTile
Cuando escuché por primera vez de Mojo, pensé que querían hacerlo compatible con el código Python existente
Pero en el futuro cercano eso parece estar muy lejos de la realidad. Puedes llamar entre Python y Mojo en ambos sentidos, pero Mojo en sí no puede ejecutar código Python existente
- En la promoción original eso sí era claramente una de las ideas centrales. Algo como que agregando type hints a código Python se obtendrían enormes mejoras de velocidad
  Pero parece que al ir construyéndolo cambiaron de rumbo
- Si mal no recuerdo, también anunciaban una mejora de velocidad de 36,000 veces frente a Python equivalente, sin dejar nada claro que eso solo era posible en casos extremos muy particulares
  Se siente más como un esquema cripto de pump and dump que como un intento honesto de mejorar el ecosistema Python
- Si uno miraba con mucha atención, desde el principio estaba claro que la idea era crear un lenguaje de sistemas de nueva generación
  Tomando lecciones de Swift y Rust, apuntando a CPU/GPU/targets heterogéneos y poniendo a MLIR en el centro
  Al mismo tiempo, parecía diseñado pensando en poder embeber o extender Python con relativa facilidad algún día, y el encuadre alrededor de Python casi seguro ayudó a conseguir financiamiento
  Chris Lattner hablaba mucho más de la relación entre MLIR y Mojo que de la relación entre Python y Mojo
- Así era la publicidad original. Querían ser algo así como Kotlin para Python, pero cambiaron de dirección muy rápido
  Por eso, y por su modelo de desarrollo no totalmente open source, siempre se sintió como vaporware
- En el sitio dice esto
  Interoperabilidad con Python: “Mojo interoperates natively with Python, allowing you to eliminate performance bottlenecks in existing code without rewriting everything. Start with a single function and scale up by moving performance-critical code to Mojo as needed. Mojo code imports naturally into Python and packages alongside it for deployment. Likewise, libraries from the Python ecosystem can be imported into Mojo code”
Mojo se ve bien, pero para cómputo numérico de alto rendimiento entre CPU y GPU, por ahora estoy bastante satisfecho con Julia
Excepto por tener una sintaxis tipo Python, siento que ese nicho ya está mayormente resuelto. Incluso Python tiene herramientas efectivas para tipos de problemas menos complejos y más independientes, como Numba y Triton
Para ese mismo objetivo, Julia está más madura, y desde el año pasado Nvidia está igualando las capacidades de sus herramientas Python y C++ para CUDA
Con el compilador JIT de Python cuTile puedes escribir kernels CUDA casi como si fuera Python puro
AMD e Intel también están siguiendo enfoques parecidos
Todavía está por verse si Mojo llegará a tiempo para lograr una adopción más amplia
- No es correcto decir que el compilador JIT de Python cuTile permite escribir kernels CUDA en Python puro. Ahora mismo no es Python puro y nunca podrá serlo
  Estos dialectos de Python “amigables con el rendimiento”, es decir Triton, Pythran, CuTile, Numba, Pycell, cuPy, etc., se ven como Python, pero apenas rascas la superficie no tienen nada de Python
  Son DSL con estilo Python diseñados para facilitar optimización e inferencia de tipos. Cuando realmente los usas, se siente así. En cada uno no puedes usar muchas, quizá la mayoría, de las funciones de Python, y aun así sigues cargando con los problemas propios de Python
  Sinceramente, Python es inherentemente malo para la eficiencia y el rendimiento
  Y eso va mucho más allá del GIL. El tipado dinámico, la semántica por referencia, el monkey patching, el modelo de objetos extremadamente dinámico, el ABI de CPython, el BigInt por defecto, el sistema de módulos en tiempo de ejecución y demás tienen sentido para un pequeño lenguaje de scripting, pero son pésimos para computación de alto rendimiento y eficiencia
  El propio ecosistema NumPy/SciPy se parece más a un hack para esquivar las limitaciones de Python y poder hacer aritmética de tensores simple limitada por CPU
  El rendimiento base de Python es tan malo que hasta un simple for loop hace que Excel parezca un caballo de carreras
  Mojo es distinto
  En vez de hackear una base existente y problemática, Mojo intenta empezar desde un punto de partida limpio
  Y busca ofrecer una “experiencia tipo Python” no sobre 30 años de Python, sino sobre un lenguaje bien diseñado construido sobre experiencias más recientes de diseño de lenguajes
  Solo por eso espero que tenga éxito
Últimamente parece que al menos para cierta gente hace falta publicidad que ponga AI native al frente
Pero a mí me genera un poco de rechazo. Porque parece una expresión que en realidad no dice nada
¿Alguien entusiasta de la IA podría explicar por qué, o qué significa, eso de “al ser un lenguaje compilado y estáticamente tipado, también es ideal para programación con agentes”?
- Desde que la IA se volvió protagonista, me ha parecido muy curioso ver la desesperación en la primera pantalla de tantos productos y servicios
  Personalmente, lo que más risa me dio fue abrir la página de producto de IBM DB2 y ver que decía AI database
  Supongo que significa que, al detectar más errores en tiempo de compilación, un agente puede verificar rápidamente su propio trabajo de forma estática sin necesidad de pruebas unitarias ni otras pruebas
- Los LLM actuales fueron entrenados con bibliotecas enormes de código del pasado. Por eso, en el futuro cercano funcionarán mejor con lenguajes ya establecidos que con lenguajes nuevos
  En especial con lenguajes como Python, donde hay muchísimo código open source disponible. Eso es un gran problema para los recién llegados, que no tienen código previo del cual aprender
  Por eso, para parecer relevante en un mundo “agentic”, quizá haga falta este marketing desesperado de AI native. El tiempo dirá si alcanza
- No me considero un fanático de la IA, pero sí la uso de verdad
  Los agentes tienden a hacerlo mejor cuanto más feedback reciben. El type checking sirve para atrapar automáticamente bastantes errores tontos
  La idea es que, en general, mientras más pistas tenga un agente, mejor
- No sé en qué sentido exacto lo usaron, y coincido en que la expresión “AI native” en un lenguaje de programación así suena algo vacía
  Sobre compilación y tipado estático, cuando haces programación con agentes ayuda muchísimo poder detectar problemas en tiempo de compilación
  Así te enfrentas a menos problemas en runtime, y también a menos situaciones difíciles de resolver para el agente. Las pruebas unitarias pueden cerrar parte de esa brecha, pero no del todo
  Lo que no dice el sitio es que Mojo probablemente sea una mala elección para programación con agentes. Todavía no hay muchos datos de entrenamiento de Mojo
- Esto es el nuevo “...on the blockchain”
  Python+ruff+pycheck y TypeScript se compilan a bytecode, no a código máquina. Tampoco tienen tipado estático en el sentido de Rust
  Aun así, he visto al modelo producir código válido bastante bueno en ambos casos. No hacía falta que fueran estrictamente “compilados” ni “estáticamente tipados”
  Al final a la IA le importan poco esas propiedades mientras tenga buenas herramientas para verificar código rápido e iterar
Modular planea liberar como open source todo el Mojo SDK, incluyendo el compilador, a finales de este año
Dice que “Mojo 1.0 quedará definido a finales de este año, junto con la publicación del compilador y la estabilidad del lenguaje”
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Sigo observando a Mojo. Sinceramente, lo que menos me gusta de Python es la sintaxis
Aquí otra persona mencionó Julia, y me parece un buen lenguaje. Pero los mensajes de error del compilador y la documentación de bibliotecas no están al nivel que esperaría de un lenguaje tan maduro
También me preocupan los problemas de exactitud en blogs que leí antes. Además, por el tamaño de los binarios y el tiempo del primer arranque, no creo que Julia me permita crear el tipo de módulo de Python que quiero
Aun así, espero que Mojo termine siendo una opción. Pero me gusta el REPL y también la naturaleza dinámica de Python, así que puede que al final no salga de NumPy por temas de rendimiento
- Para mí es al revés. Lo único que me gusta de Python es la sintaxis
  Por eso me gusta muchísimo Nim. Obtienes velocidad de nivel C, ejecución en tiempo de compilación, metaprogramación, un sistema de tipos potente y seguridad de memoria, y aun así el código suele ser corto y elegante
  Mojo también me parece interesante, pero hasta ahora parece estar más enfocado en machine learning que en programación general. Y hasta donde sé, el compilador todavía no es open source
- Me gusta muchísimo el diseño de Mojo. Como tiene gestión determinista de memoria, no se puede comparar con Julia
  También parece que Mojo está más enfocado en convertirse en un lenguaje robusto para uso industrial. Me impactó ver que la primera implementación de precompilación de Julia no ofrecía entrada/salida de archivos

Mojo 1.0 beta

Versiones y recursos para empezar

GPU e interoperabilidad con Python

Programación para GPU

Interoperabilidad con Python

Metaprogramación en tiempo de compilación

Hoja de ruta y open source

Phase 0

Phase 1

Phase 2

Phase 3

Recursos de aprendizaje y comunidad

Lecturas relacionadas

1 comentarios

Comentarios en Hacker News