Mojo 1.0 bêta

(mojolang.org)

3 points par GN⁺ 7 시간 전 | 1 commentaires | Partager sur WhatsApp

Mojo se présente comme un langage qui permet de « l’écrire comme en Python, l’exécuter comme en C++ » et propose actuellement la version stable 1.0.0b1 (7 mai)
Il vise à permettre l’écriture de code rapide sur une grande variété de matériels, du CPU au GPU, sans dépendre d’un fournisseur spécifique, et a été conçu comme un langage statiquement typé haute performance pour les systèmes d’IA modernes
Il prend en charge l’interopérabilité avec Python nativement, ce qui permet de déplacer uniquement les goulets d’étranglement de performance vers Mojo sans réécrire tout le code existant ; il prend en charge à la fois l’import de code Mojo depuis Python et l’import de bibliothèques Python dans Mojo
Il permet d’écrire des kernels GPU dans le même langage, et cherche à fournir des optimisations spécifiques au matériel ainsi que des abstractions sans coût grâce à la métaprogrammation à la compilation utilisant le même langage que le code d’exécution
La bibliothèque standard de Mojo est entièrement open source sur GitHub et accepte les contributions ; le compilateur Mojo prévoit d’être open source en 2026

Versions et ressources de démarrage

La version stable actuelle est 1.0.0b1 (7 mai), et la dernière nightly est celle du 9 mai
Mojo s’inspire de la syntaxe intuitive de Python, de la sûreté mémoire de Rust, et de la métaprogrammation à la compilation puissante et intuitive de Zig
En tant que langage compilé et statiquement typé, il convient aussi à la programmation orientée agents
Son objectif est d’offrir à la fois productivité et performances, plutôt que de forcer à choisir entre les deux ; on peut commencer avec des patterns de programmation simples et familiers, puis ajouter de la complexité quand c’est nécessaire
Pour démarrer, sont proposés : Install Now, Quickstart, Releases, Roadmap, GitHub
Pour afficher une page en Markdown, on peut ajouter .md à l’URL, et l’index complet de la documentation Mojo est disponible dans llms.txt

GPU et interopérabilité avec Python

Programmation GPU

Mojo vise à rendre la programmation GPU accessible sans bibliothèques spécifiques à un fournisseur ni code compilé séparément
Il permet d’écrire des kernels GPU haute performance dans le même langage que pour le CPU

Le kernel d’exemple vector_add reçoit des TileTensor et effectue result[i] = a[i] + b[i] en se basant sur global_idx.x

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]

Interopérabilité avec Python
- Mojo est nativement interopérable avec Python, ce qui permet d’éliminer les goulets d’étranglement de performance sans réécrire entièrement le code existant
- On peut commencer par une seule fonction, puis étendre progressivement en déplaçant vers Mojo le code critique pour les performances selon les besoins
- Le code Mojo peut être importé naturellement dans Python et être empaqueté avec les packages destinés au déploiement
- À l’inverse, le code Mojo peut aussi importer des bibliothèques de l’écosystème Python
- La fonction d’exemple mojo_square_array obtient un pointeur depuis ctypes.data d’un PythonObject, calcule la largeur SIMD à la compilation, puis met au carré les éléments du tableau
```
# 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)  
```

Métaprogrammation à la compilation

La métaprogrammation de Mojo fournit un système intuitif qui maximise les performances en utilisant le même langage que le code d’exécution
Elle permet de créer des optimisations spécifiques au matériel via la compilation conditionnelle, de garantir la sûreté mémoire grâce à l’évaluation à la compilation, et d’éliminer les branchements d’exécution coûteux
L’objectif est d’offrir des abstractions sans coût tout en exprimant clairement l’intention

L’implémentation d’exemple de __eq__ utilise la réflexion à la compilation pour obtenir les noms et types des champs d’une struct, vérifier que tous les champs satisfont Equatable, puis effectuer l’égalité champ par champ

# 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

Feuille de route et open source

Mojo a démarré fin 2022 et il reste encore beaucoup à faire
Phase 0
- Étape de mise en place des bases initiales
- Cette étape consiste à implémenter le parseur central, les types mémoire, les fonctions, les structs, les initialiseurs, les conventions d’appel et d’autres fondations du langage
Phase 1
- Étape actuellement en cours
- L’objectif est d’en faire un langage puissant et expressif pour écrire des kernels haute performance sur CPU, GPU et ASIC, tout en permettant aux développeurs d’étendre Python de manière fluide
Phase 2
- Étape de programmation d’applications système
- Cette étape vise à l’étendre pour prendre en charge un modèle de sûreté mémoire garanti ainsi que davantage de capacités d’abstraction attendues par les développeurs en programmation système
Phase 3
- Étape de programmation orientée objet dynamique
- Cette étape consiste à prendre davantage en charge les fonctionnalités dynamiques de Python, comme les classes, l’héritage et les variables non typées, afin de maximiser la compatibilité avec le code Python
- Plus de détails sont disponibles dans la Mojo roadmap
- La bibliothèque standard de Mojo est entièrement open source sur GitHub et accepte les contributions
- Le compilateur Mojo prévoit d’être open source en 2026
- Même si l’orientation est d’open sourcer l’ensemble de Mojo, l’équipe estime que, le langage étant encore très jeune, un groupe d’ingénieurs étroitement aligné sur une vision commune peut avancer plus vite qu’un modèle piloté par la communauté
- Une voie de participation est proposée via la developer community

Ressources d’apprentissage et communauté

Install et Quickstart guide : ressources pour démarrer avec Mojo
Beginner tutorial : apprendre Mojo en créant un Game of Life
GPU puzzles : apprendre la programmation GPU avec Mojo en résolvant des puzzles
Intro to Mojo : présentation générale des fonctionnalités du langage Mojo
Developer forum : questions et mises à jour autour de Mojo
Events : événements, meetups, présentations et hackathons
Contributions : informations sur les issues ouvertes, les contributions à la documentation et le partage de projets

1 commentaires

GN⁺ 7 시간 전

Avis sur Hacker News

J’ai beaucoup utilisé Mojo pour le plaisir ces deux dernières années, et c’est vraiment un langage génial
Il a un modèle de possession proche de Rust, une exécution à la compilation plus puissante que Zig, un système de types riche et une prise en charge SIMD de premier ordre
Côté performances aussi, cela ressemble enfin à un vrai langage plutôt qu’à un simple wrapper LLVM. LLVM est toujours utilisé, mais d’une manière différente de Rust ou Zig
J’attends vraiment beaucoup de Mojo quand il passera en open source plus tard cette année
- J’aimerais bien que tu expliques un peu plus ce que tu entends par « une exécution à la compilation plus puissante que Zig »
  Rien que d’après la documentation de Mojo, il est difficile d’arriver à cette conclusion
En tant que personne qui fait du machine learning tout en s’intéressant aux performances, j’espère que Mojo réussira. En particulier, le fait de pouvoir mélanger du code GPU et du code CPU dans le même langage est prometteur
Cela dit, je crains que les changements actuels n’éloignent les développeurs Python. La dernière fois que j’ai essayé, je voulais juste tester une manipulation de chaîne basique avec var x = 'hello'; print(x[3]), mais ça ne marchait pas, et len(x) non plus, ce qui m’a fait perdre une heure
Il s’est avéré qu’ils avaient décidé de distinguer plus précisément les représentations en octets et en points de code, mais la documentation contredisait l’implémentation réelle
J’aimerais qu’il devienne exploitable aussi pour le machine learning généraliste, mais pour l’instant cela reste assez limité. Certaines fonctionnalités de base correctes autour des tenseurs ont aussi été supprimées
Pour le moment, je vais rester sur JAX et jeter un œil de temps en temps
- Je ne comprends pas pourquoi il n’existe toujours pas un langage capable de transformer un simple code centré sur le calcul, avec un minimum de syntaxe supplémentaire, en code SIMD / multithread / multiprocessus / GPU
  Ça ressemble pourtant au genre de rêve que devraient avoir les gens passionnés par les compilateurs et la conception de langages
  Il n’a pas besoin de garantir l’efficacité dans tous les cas ni d’offrir des performances de pointe, le simple fait qu’il existe serait déjà bien
  Je comprends qu’un tel langage soit faisable, mais il semble ne pas avoir réussi à susciter l’intérêt des personnes capables de le construire
- Mojo est cool, mais je ne comprends pas pourquoi ils s’accrochent à la rétrocompatibilité avec Python. C’est ce qui les freine eux-mêmes
  Presque tous les défauts qui me viennent à l’esprit avec Kotlin viennent de sa compatibilité avec Java. Ici, ils auraient peut-être pu mieux le résoudre de façon plus explicite, mais dans sa forme actuelle, cela semble voué à l’échec
- Si ce n’est pas open source, ça n’a pas vraiment d’intérêt. La plupart des développeurs Python ne viendront de toute façon pas
- Sous cet angle, on dirait presque qu’ils essaient de recréer le langage de programmation Nim
Il est écrit qu’« ils ont promis de publier Mojo en open source à l’automne 2026 »
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Ce serait bien de pouvoir voir le code source de vrais programmes MLIR de pointe
Malheureusement, pendant ce temps Nvidia n’est pas resté immobile non plus, et a créé une CUDA de nouvelle génération appelée CuTile pour Python, et bientôt pour C++, via une pile de compilation similaire basée sur MLIR
Même sans portabilité, il y a de fortes chances que ce soit bien plus utilisé que Mojo, simplement parce que Nvidia va pousser fort, l’intégrer à ses outils de développement et le faire coexister avec le code CUDA existant
Tile IR relevait probablement davantage d’une réponse à la menace de Triton que de Mojo. C’est particulièrement vrai si on se place du point de vue de la facilité avec laquelle on peut écrire des noyaux LLM aux performances correctes
- Pour ne pas se laisser distancer, Intel et AMD font aussi des efforts similaires, et le JIT de CPython devient enfin réalité après plusieurs tentatives
  Il y a aussi des essais comme GraalPy et PyPy
  Tous ces efforts fonctionnent aujourd’hui sous Windows. C’est assez important dans les environnements où la plupart des employés reçoivent des machines Windows au travail et où seuls les serveurs utilisent une distribution Linux
  Ça me fait encore penser à une possible fin à la Swift for Tensorflow
- D’après ce que m’ont dit quelques développeurs de Tile IR, la motivation principale était d’offrir une meilleure portabilité de la programmation des tensor cores que PTX
  En dehors des retours clients, personne n’a parlé d’une réponse à quoi que ce soit
- Beaucoup de gens semblent croire que Mojo n’est qu’une syntaxe pratique pour écrire du code GPU, et que le framework Python de Nvidia remplit déjà ce rôle
  Mais est-ce que CuTile fonctionnera aussi sur des GPU AMD ou sur Apple Silicon ? Quoi que fasse Nvidia, la dépendance fournisseur reste entière
- Je me demande à quel point l’impact de CuTile sera important
Quand j’ai entendu parler de Mojo au début, j’ai cru qu’ils essayaient de le rendre compatible avec le code Python existant
Mais à court terme, cet objectif paraît désormais très lointain. On pourra appeler du code dans les deux sens entre Python et Mojo, mais Mojo lui-même ne peut pas exécuter le code Python existant
- Dans leur communication initiale, c’était clairement présenté comme l’un des points centraux. L’idée était qu’en ajoutant des indications de types au code Python, on obtiendrait d’énormes gains de vitesse
  Mais au fur et à mesure de la construction, ils semblent avoir changé de direction
- Si je me souviens bien, ils ont aussi vanté un gain de vitesse de 36 000x par rapport à Python équivalent, sans jamais préciser clairement que cela n’était possible que dans des cas limites extrêmes
  Cela donnait moins l’impression d’un effort honnête pour améliorer l’écosystème Python que d’un montage crypto façon pump and dump
- En regardant de très près, il était pourtant clair dès le départ que l’idée consistait à créer un langage système de nouvelle génération
  Il reprenait les enseignements de Swift et Rust, visait le CPU, le GPU et les cibles hétérogènes, et plaçait MLIR au centre
  En même temps, l’architecture semblait pensée pour permettre un jour d’embarquer ou d’étendre Python relativement facilement, et le cadrage autour de Python a presque certainement aidé à lever des fonds
  Chris Lattner a davantage parlé de la relation entre MLIR et Mojo que de celle entre Python et Mojo
- La publicité initiale allait dans ce sens. Ils voulaient être une sorte de Kotlin pour Python, puis ont très vite changé de cap
  Entre ce point et leur modèle de développement pas totalement open source, ça m’a toujours donné une impression de vaporware
- Voici ce qu’on lit sur le site
  Interopérabilité Python : « Mojo est interopérable nativement avec Python, ce qui vous permet d’éliminer les goulets d’étranglement de performance dans le code existant sans tout réécrire. Vous pouvez commencer par une seule fonction et étendre progressivement en migrant vers Mojo le code critique pour les performances selon les besoins. Le code Mojo s’importe naturellement dans Python et peut être empaqueté avec lui pour le déploiement. De même, les bibliothèques de l’écosystème Python peuvent être importées dans le code Mojo »
Mojo a l’air correct, mais pour le calcul numérique haute performance couvrant CPU et GPU, je suis actuellement assez satisfait de Julia
Mis à part la syntaxe à la Python, j’ai l’impression que cette niche est déjà largement couverte. Même Python dispose déjà d’outils efficaces comme Numba et Triton pour des problèmes moins complexes et plus ciblés
Pour le même objectif, Julia est plus mature, et depuis l’an dernier Nvidia aligne les fonctionnalités de ses outils Python et C++ pour CUDA
Avec le compilateur JIT Python cuTile, on peut écrire des noyaux CUDA comme en pur Python
AMD et Intel suivent aussi une approche similaire
Il reste à voir si Mojo arrivera à temps pour obtenir une adoption plus large
- Dire que le compilateur JIT Python cuTile permet d’écrire des noyaux CUDA en pur Python n’est pas correct. Ce n’est déjà pas du pur Python aujourd’hui, et cela ne pourra jamais l’être
  Tous ces dialectes Python « favorables à la performance », comme Triton, Pythran, CuTile, Numba, Pycell, cuPy, etc., ressemblent à Python en surface, mais dès qu’on gratte un peu, ce n’est plus du Python du tout
  Ce sont des DSL à la saveur Python conçus pour faciliter l’optimisation et l’inférence de types. Dès qu’on les utilise réellement, on le sent
  Dans chacun d’eux, beaucoup, voire la plupart, des fonctionnalités de Python ne sont pas disponibles, tout en conservant malgré cela les problèmes propres à Python
  Franchement, Python n’est pas intrinsèquement bon pour l’efficacité et la performance
  Le problème va bien au-delà du GIL. Le typage dynamique, la sémantique par référence, le monkey patching, le modèle objet extrêmement dynamique, l’ABI de CPython, les BigInt par défaut, le système de modules à l’exécution, etc., ont du sens pour un petit langage de scripting, mais sont très mauvais pour le calcul haute performance et l’efficacité
  L’écosystème NumPy/SciPy lui-même ressemble déjà à un ensemble de contournements pour échapper aux limites de Python dans le cadre d’une simple arithmétique tensorielle CPU-bound
  Les performances de base de Python sont si faibles que de simples boucles for font presque passer Excel pour un pur-sang
  Mojo, c’est différent
  Au lieu de bricoler sur une base existante et problématique, Mojo essaie de repartir d’une base propre
  Et plutôt que de s’appuyer sur un Python vieux de plus de 30 ans, il veut offrir une « expérience proche de Python » avec un langage bien conçu, bâti sur les enseignements accumulés en conception de langages
  Rien que pour ça, j’espère qu’il réussira
De nos jours, on dirait qu’au moins une partie du public a besoin d’une communication mettant AI native au premier plan
Mais personnellement, cela me rebute un peu. On dirait une formule qui ne veut en réalité rien dire
Est-ce que les passionnés d’IA peuvent m’expliquer pourquoi « étant compilé et statiquement typé, c’est aussi idéal pour la programmation par agents », et même ce que cela signifie exactement ?
- Depuis que l’IA est mise en avant, il était vraiment intéressant de voir ce sentiment de panique sur les pages d’accueil de ce genre de produits et services
  Personnellement, le plus drôle a été d’ouvrir la page produit d’IBM DB2 et de voir l’étiquette AI database
  J’imagine que cela veut dire qu’en attrapant davantage d’erreurs à la compilation, un agent peut vérifier rapidement son propre travail de manière statique, sans tests unitaires ni autres tests
- Les LLM actuels ont été entraînés sur d’immenses bibliothèques de code ancien. À court terme, ils fonctionneront donc probablement mieux avec des langages déjà bien établis qu’avec un langage nouveau
  C’est particulièrement vrai pour des langages comme Python, où il existe énormément de code open source disponible. Pour un nouvel entrant, ne pas avoir de base de code existante sur laquelle apprendre est un vrai problème
  Donc, pour paraître pertinent dans un monde « agentique », ce type de marketing AI native est peut-être nécessaire. Reste à voir si cela suffira
- Je ne me considère pas comme un utilisateur fanatique de l’IA, mais je m’en sers réellement
  Les agents ont tendance à mieux s’en sortir lorsqu’ils reçoivent beaucoup de retours. La vérification de types est très utile pour détecter automatiquement beaucoup d’erreurs stupides
  En gros, plus on donne d’indices à un agent, mieux c’est en général
- Je ne sais pas exactement ce qu’ils voulaient dire par là, et je suis d’accord pour dire que l’expression « AI native » est assez vide de sens dans ce type de langage de programmation
  En ce qui concerne la compilation et le typage statique, dans la programmation par agents, c’est effectivement très utile de pouvoir détecter les problèmes à la compilation
  Cela réduit les problèmes qui n’apparaissent qu’à l’exécution, ainsi que les situations plus difficiles à résoudre pour un agent. Les tests unitaires peuvent combler une partie du manque, mais pas entièrement
  Ce qui n’est pas indiqué sur leur site, c’est que Mojo est probablement plutôt un mauvais choix pour la programmation par agents. Il n’existe pas encore beaucoup de données d’entraînement pour Mojo
- C’est le nouveau « ...on the blockchain »
  Python+ruff+pycheck et TypeScript se compilent en bytecode, pas en code machine. Et ils ne sont pas non plus statiquement typés au sens de Rust
  Pourtant, j’ai vu des modèles produire du code valide plutôt bon dans les deux cas. Il n’était pas nécessaire que ce soit strictement « compilé » ou « statiquement typé »
  Au final, l’IA se moque assez de ces propriétés dès lors qu’elle dispose de bons outils pour vérifier rapidement le code et itérer
Modular prévoit de publier en open source plus tard cette année l’intégralité du SDK Mojo, y compris le compilateur
On peut lire que « Mojo 1.0 sera finalisé plus tard cette année, avec la publication du compilateur et la stabilité du langage »
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Je continue de suivre Mojo. Honnêtement, ce que j’aime le moins dans Python, c’est sa syntaxe
Quelqu’un ici a mentionné Julia, et je pense que c’est un bon langage. Mais les messages d’erreur du compilateur et la documentation des bibliothèques ne sont pas au niveau qu’on attendrait d’un langage aussi mature
Les problèmes de fiabilité dans certains billets de blog que j’ai lus il y a quelque temps m’inquiètent aussi. Et à cause de la taille des binaires et du temps de démarrage initial, je ne pense pas pouvoir créer avec Julia le genre de module Python que je voudrais
Cela dit, j’espère quand même que Mojo deviendra une vraie option. J’aime le REPL et j’aime aussi le caractère dynamique de Python, donc il est possible qu’au final je ne sorte jamais de NumPy pour des raisons de performance
- Pour moi, c’est l’inverse. La seule chose que j’aime vraiment dans Python, c’est sa syntaxe
  C’est pour ça que j’aime beaucoup Nim. On y gagne une vitesse de niveau C, l’exécution à la compilation, la métaprogrammation, un système de types puissant et la sécurité mémoire, tout en gardant un code souvent court et élégant
  Mojo est intéressant aussi, mais jusqu’ici il semble surtout orienté machine learning plutôt que programmation généraliste. Et si je ne me trompe pas, le compilateur n’est toujours pas open source
- J’aime énormément la conception de Mojo. Avec sa gestion mémoire déterministe, il n’est pas vraiment comparable à Julia
  J’ai aussi l’impression que Mojo vise davantage à devenir un langage robuste pour l’industrie. J’ai été choqué de voir que la première implémentation de la précompilation de Julia ne fournissait même pas d’entrées-sorties fichier

Mojo 1.0 bêta

Versions et ressources de démarrage

GPU et interopérabilité avec Python

Programmation GPU

Interopérabilité avec Python

Métaprogrammation à la compilation

Feuille de route et open source

Phase 0

Phase 1

Phase 2

Phase 3

Ressources d’apprentissage et communauté

À lire aussi

1 commentaires

Avis sur Hacker News