- Chris Lattner est l’un des principaux développeurs de LLVM et du langage Swift, et il développe actuellement le nouveau langage Mojo afin d’exploiter au maximum les performances du matériel ML moderne.
- Mojo vise à être un langage offrant à la fois facilité d’usage et contrôle fin des détails matériels, en s’appuyant sur la métaprogrammation sûre du point de vue des types pour gérer efficacement les spécificités du matériel.
- Le contexte principal est la volonté de construire une plateforme de calcul unifiée pour résoudre la fragmentation de l’écosystème des accélérateurs IA — GPU, TPU, ASIC, etc. — et réduire la dépendance à un fournisseur donné.
- En raison des problèmes de compatibilité et de complexité des piles logicielles GPU existantes (CUDA, ROCm, XLA, etc.), le développement d’un langage de nouvelle génération alliant hautes performances et portabilité est devenu indispensable.
- Modular poursuit un modèle économique centré sur la résolution de problèmes concrets, en proposant Mojo gratuitement, avec une prise en charge matérielle unifiée et des services destinés aux entreprises.
Présentation de Chris Lattner et de sa carrière
- Chris Lattner a dirigé plusieurs projets fondamentaux dans le domaine du calcul, dont LLVM, Clang, MLIR, Swift et Mojo.
- Il a travaillé chez Apple, Tesla, Google, SiFive, Modular et d’autres organisations, acquérant une vaste expérience pratique en conception de compilateurs et de langages de programmation.
- À ses débuts, il est parti de langages simples comme BASIC et de l’univers du PC, avant de s’intéresser à l’exploitation maximale des performances matérielles à travers les jeux et le graphisme.
- À l’université, l’influence fortuite d’un professeur spécialiste des compilateurs lui a fait découvrir l’attrait des systèmes et de l’architecture logicielle à grande échelle.
Entre ingénierie des compilateurs et conception des langages
- Chris Lattner a travaillé à la fois sur l’ingénierie des compilateurs et la conception des langages, et a accompli l’essentiel de ses réalisations à l’intersection de ces deux domaines.
- LLVM, par exemple, est une représentation intermédiaire utilisable par de nombreux langages ; au-delà de son implémentation en C++, il a donné naissance à de nombreux cas d’usage, notamment avec Rust et Julia.
- Le développement de Swift est lui aussi né d’une volonté de dépasser les limites et la fatigue liées aux implémentations existantes en C++, avec une forte attention portée au besoin de fonctions pratiques comme le pattern matching.
- En matière d’innovation dans les langages, il privilégie une approche de conception fondée sur la résolution de problèmes concrets et l’utilité, plutôt que sur la seule théorie mathématique.
Théorie des langages de programmation et pragmatisme
- Chris privilégie une manière de penser centrée sur la résolution de problèmes plutôt que sur la rigueur mathématique, et dans les articles de recherche sur les langages de programmation, il s’intéresse davantage aux exemples concrets et aux usages qu’à la théorie elle-même.
- Il reconnaît que les fonctionnalités de langage reposant sur de solides bases mathématiques ont des avantages en matière de cohérence et de composabilité, mais que l’adoption réelle est avant tout portée par leur utilité visible à l’usage.
- Il souligne aussi que, pour de nouveaux langages ou de nouvelles technologies, il est important de réduire autant que possible le « grain de sable » de complexité, afin de favoriser la simplicité de conception et la capacité d’extension.
Les problèmes structurels de l’écosystème matériel de l’IA
- L’infrastructure traditionnelle des compilateurs (LLVM) était centrée sur les CPU, alors que l’IA et le machine learning exigent divers matériels spécialisés comme les GPU, TPU, ASIC et FPGA.
- Chaque fournisseur développe sa propre pile logicielle (CUDA, ROCm, XLA, etc.), ce qui entraîne un manque de compatibilité et une fragmentation de l’écosystème.
- Les logiciels ML, comme PyTorch par exemple, nécessitent des optimisations distinctes selon le fournisseur matériel, ce qui rend la maintenance et l’évolution extrêmement difficiles.
- Comme les piles, les langages et les écosystèmes d’outils diffèrent selon le matériel, les développeurs logiciels subissent largement une baisse de productivité et de portabilité.
Le rôle de Modular et de Mojo
- L’équipe de Modular se concentre sur la création d’une plateforme logicielle générale et unifiée pour résoudre ces problèmes.
- Mojo est conçu non seulement pour tirer parti des performances des architectures GPU modernes comme les Tensor Cores, mais aussi pour permettre l’écriture de kernels portables sur différents matériels.
- Grâce à une architecture multicouche comprenant Mojo, MAX (serving LLM haute performance, etc.) et Mammoth (gestion de clusters/Kubernetes), Modular propose une infrastructure IA intégrée.
Pourquoi Mojo est nécessaire et quels choix de conception ont été faits
- Les langages existants ne permettent pas de satisfaire simultanément les deux exigences que sont la portabilité des kernels ML haute performance et l’optimisation spécifique aux fournisseurs.
- Mojo doit pouvoir s’adapter dynamiquement aux détails matériels — par exemple à divers types de données comme les flottants 8 bits — ainsi qu’à des composants comme les Tensor Cores, dans un environnement matériel en évolution extrêmement rapide.
- Grâce à un modèle de métaprogrammation garantissant la sûreté des types, il transforme un contrôle matériel complexe en une approche plus efficace et plus facilement partageable.
L’évolution du matériel et de la conception des kernels
- Dans les datacenters modernes, les CPU se sont étendus à un grand nombre de cœurs, tandis que les GPU ont rapidement évolué avec une conception spécialisée dans le traitement parallèle, fondée notamment sur les SM (Streaming Multiprocessors) et les warps (groupes de 32 threads).
- Avec l’introduction dans le matériel d’unités de calcul dédiées à l’IA comme les Tensor Cores, un paradigme de programmation matérielle totalement différent du CUDA traditionnel est devenu nécessaire.
- Même chez un même fournisseur, les changements de compatibilité entre générations d’architecture sont fréquents (par exemple chez Nvidia entre Volta, Hopper et Blackwell), et les piles logicielles peinent à suivre.
Modèle économique et stratégie d’écosystème ouvert
- Modular ne cherche pas à vendre le langage lui-même et met Mojo gratuitement à disposition.
- Son modèle de revenus principal repose sur la gestion unifiée du matériel et sur la fourniture de plateformes et de services pour les entreprises.
- L’objectif est ainsi de construire un écosystème commun sans verrouillage fournisseur, tout en poursuivant à la fois le support de matériels variés et une gestion efficace de l’infrastructure.
Conclusion
- Le projet Mojo de Chris Lattner et Modular représente une nouvelle plateforme et un nouveau langage de programmation destinés à accompagner l’essor du machine learning, l’innovation du matériel IA et le dépassement de la fragmentation de l’écosystème.
- Grâce à une conception de langage innovante et à la diffusion d’un écosystème ouvert, cette stratégie vise à contribuer à la démocratisation de l’écosystème IA et à l’amélioration de la productivité.
1 commentaires
Commentaires sur Hacker News
Je tiens à remercier tous ceux qui se sont intéressés à Mojo et au podcast. Si vous voulez en savoir plus sur Mojo, vous pouvez consulter les questions fréquentes dans la FAQ (y compris la réponse à « pourquoi ne pas simplement améliorer Julia ? »). La documentation est également disponible ici, et le code open source publié représente déjà plusieurs centaines de milliers de lignes. La communauté Mojo est aussi vraiment excellente, donc n’hésitez pas à nous rejoindre sur le forum Discourse ou le chat Discord — commentaire de Chris Lattner
Je suis fan. J’ai regardé plusieurs présentations sur Mojo, et même si l’on dit que Mojo s’appuie sur des technologies de compilateur de pointe, je n’ai jamais vu d’exemples concrets. Même sans être développeur de compilateurs, j’aimerais pouvoir en saisir ne serait-ce que 20 % pour mieux sentir ce que ces techniques ont de vraiment avancé, donc j’aimerais beaucoup un billet de blog très approfondi et très technique
La FAQ pose la question « Mojo Playground est-il toujours disponible ? » et renvoie vers ce playground, mais sur place il est indiqué que le Playground sera supprimé dans la prochaine release 25.6. Répondre dans la FAQ à « est-ce disponible ? » en pointant vers une fonctionnalité sur le point de disparaître passe un peu à côté du sujet. En pratique, la vraie réponse semble être : « oui, mais plus pour longtemps »
Chris, ravi de te voir ici. J’avais même investi à l’époque via Light Table, et je me demandais s’il y avait des nouvelles. (Je ne pose pas la question tout à fait sérieusement, même si Mojo a l’air cool.) Je me demande quelle est la viabilité à long terme de ce genre de projet et s’il existe des éléments solides permettant d’avoir confiance
Si Python domine le ML, c’est parce que les applications modernes de ML ne sont pas de simples scripts de calcul, mais exigent des fonctionnalités très larges et un écosystème robuste. Prétraitement de données (ETL), gestion de multiples formats, traitement distribué sur des clusters de calcul haute performance, visualisation, intégration GUI/DB : aucune autre langue ne couvre tout cela comme Python. Pour le calcul numérique, NumPy, PyTorch, JAX, etc. s’appuient en interne sur du C/C++/FORTRAN, donc c’est très rapide, et il est facile d’implémenter séparément en C/C++ uniquement les portions critiques pour les performances. Le système FFI C/C++ de Python est aussi largement assez pratique par rapport à celui d’autres langages. C’est bien plus avantageux que de réimplémenter tout l’écosystème dans un autre langage comme Julia
L’écosystème Python est sans équivalent, mais la combinaison Elixir/Nx fait déjà une grande partie de ce que promet Mojo. Via EXLA, on peut compiler pour GPU/TPU ; pour les dataframes, il y a Explorer/Polars ; et avec Pythonx, on peut intégrer des bibliothèques Python. La différence, c’est qu’Elixir a été pensé dès le départ pour construire des systèmes distribués, donc BEAM/OTP peut gérer d’énormes volumes de requêtes concurrentes ainsi que l’orchestration entre nœuds GPU. Si l’on construit un vrai service ML, obtenir une pile unifiée et solide avec Phoenix, LiveView et Nx, avec une tolérance aux pannes extrême et une forte scalabilité, peut compter davantage que de petits gains de performance matérielle
J’ai un point de vue un peu différent sur l’inference. Il est facile de bricoler directement des kernels CUDA, et le dernier CUTLASS 3 ainsi que le C++ moderne sont devenus bien plus pratiques. Torch n’est qu’une fine couche au-dessus, mais cette partie est difficile à build et ajoute de la complexité, notamment avec le comptage de références et d’autres problèmes. Le cœur réel de l’implémentation se trouve dans les kernels sous-jacents, et je pense bientôt enlever cette « couverture Torch » pour relier tout cela plus clairement dans un programme C++ propre
Le problème ici concerne les kernels GPU, mais ces kernels ne sont de toute façon pas écrits en Python. Python est le langage de « glue » du ML. Je suis d’accord avec l’idée que « seul Python fournit toutes les briques », mais c’est quand même un peu regrettable que l’écosystème ait grandi principalement autour de Python plutôt que d’un meilleur langage
Si Python est devenu le langage de référence du ML, c’est un « cercle vertueux ». L’écosystème a grossi parce qu’il avait déjà été choisi, mais cela n’explique pas pourquoi il a été choisi au départ. Aujourd’hui il est devenu si énorme qu’il semble impossible à détrôner, mais cela reste un argument insuffisant pour expliquer pourquoi c’était Python dès le début
Ironiquement, Python est le pire langage possible pour toutes les tâches que tu mentionnes. Le packaging et les binaires (wheels) sont pénibles, et il y a toujours quelque chose qui casse. Pour des scripts autonomes, ça va, mais si Python avait été conçu avec l’objectif de devenir le langage principal du ML, personne n’aurait voulu qu’il ressemble à ça
J’ai été choqué en écoutant l’épisode. Entendre qu’en septembre 2025 le support des classes reste encore un objectif à moyen terme m’a surpris. À une époque, Mojo était beaucoup présenté comme un « surensemble de Python », mais au rythme actuel, cela ressemble davantage à un objectif idéal qu’à quelque chose de réaliste
En réalité, l’objectif n’a jamais été d’être un « surensemble de Python ». C’était surtout un slogan pour capter l’attention ; c’était mis en avant au début puis discrètement abandonné
Je me demande si ce n’est pas moins un problème de vitesse qu’un simple désintérêt pour la POO elle-même
Cela a toujours été un objectif de long terme
C’est peut-être une question un peu classique, mais je me demande pourquoi ce n’était pas Lisp. Si l’on part du principe que le code ML du futur sera de toute façon écrit par des machines (ou par des systèmes de transformation automatique basés sur le langage naturel), alors les S-expressions de Lisp sont pratiquement des AST, donc c’est le langage le plus naturel pour les machines. Et comme l’environnement REPL est généralement complet, cela semble aussi très bien convenir comme remplaçant de Python
Yann LeCun et d’autres avaient créé Lush, un Lisp pour le ML. C’était ce qu’il y avait de mieux dans les années 2000, avant l’arrivée de Python (Theano) ou Lua (Torch), et il n’y avait pas vraiment d’alternative. J’aimerais bien que Lisp revienne davantage sur le devant de la scène. Les bibliothèques Python sont excellentes, mais le langage lui-même a encore beaucoup de points à améliorer
Les LLM (grands modèles de langage) ne sont pas encore très bons pour compter les parenthèses ;)
Lors du précédent boom de l’IA, Lisp a déjà fait l’expérience d’être délaissé, et beaucoup de développeurs utilisent encore uniquement Emacs + SBCL. En réalité, il existe d’autres implémentations Lisp avancées comme LispWorks, Allegro ou Clozure, mais beaucoup de gens ne les ont simplement jamais essayées
Je n’aime déjà pas la licence de Mojo
J’ai vérifié aussi : la licence de Mojo distingue les usages CPU ou Nvidia des autres « accélérateurs » (TPU, AMD, etc.), et indique qu’un usage commercial nécessite une licence séparée voir le billet de blog
De mon point de vue, s’il s’agit d’un langage (Mojo) entièrement contrôlé par une entreprise donnée, il n’y a absolument aucune raison de l’adopter dans un contexte business. Beaucoup d’entreprises ont déjà eu des problèmes lors des changements de licence de Java. Bâtir une activité sur Mojo plutôt que sur Python est un risque excessif
En lisant la FAQ de Mojo, on comprend qu’au sens strict ils visent bien un surensemble de Python, mais la roadmap dit aussi : « offrir un code Python et une familiarité avec Python, sans pouvoir être un surensemble complet », ce qui ne fait qu’ajouter à la confusion. Si la compatibilité Python n’est pas l’objectif, je ne comprends pas pourquoi Python est encore autant mentionné. Et je me demande aussi si l’histoire de l’extension de fichier en emoji est réelle
D’après ce que je sais, Mojo vise surtout une syntaxe de style Python et l’interopérabilité avec Python. Tout ce qui donne l’impression qu’il est plus proche encore de Python relève surtout du marketing
Pour l’extension en emoji, oui, c’est bien réel. C’est U+2615 (l’emoji café)
J’aimerais comprendre en quoi Mojo serait supérieur à Julia. Julia a certes ses limites en matière d’interfaces ou d’écosystème, mais l’interopérabilité avec Python fonctionne déjà très bien, donc je ne vois pas vraiment en quoi Mojo serait meilleur
Julia dispose notamment d’un bon écosystème GPU, avec JuliaGPU et Reactant voir Reactant.jl
La compatibilité avec Python est peut-être un peu meilleure côté Mojo, mais en pratique l’appel de bibliothèques Python depuis Julia via PythonCall.jl est déjà assez stable. Les frameworks ML (Lux.jl, Flux.jl) fonctionnent aussi bien dans l’écosystème Julia. Mojo ne semble pas encore avoir de framework ML natif d’un niveau comparable
Mojo semble viser un langage beaucoup plus bas niveau, avec davantage de contrôle et de robustesse. Julia, lui, est moins prévisible en termes de sémantique ou de performances, donc moins adapté comme base logicielle centrale, alors que Mojo a un avantage sur ce point
J’ai essayé de créer des modules Python en Julia, mais j’ai trouvé que le support était encore insuffisant. Pour Mojo, c’est une fonctionnalité centrale
Julia manque encore de capacité pour compiler son code en binaires totalement natifs, à la manière de Rust ou C++
Le fait que Mojo n’ait pas suscité un engouement massif et que l’usage de PyTorch reste dominant peut être un indice que les questions de licence pèsent réellement davantage que prévu
Mojo a peut-être visé son terrain de jeu avec trop d’optimisme. L’usage commercial de Julia augmente aussi progressivement, et le support GPU est bon. Même si le compilateur JIT de Python reste imparfait, Nvidia, Intel et d’autres optimisent déjà très bien la programmation GPGPU via des DSL Python, au point de permettre un usage proche du niveau C++ depuis Python. Au final, Mojo se différencie assez peu
D’un point de vue systèmes, la tentative de Chris et de son équipe d’éliminer proprement les problèmes de FFI multilangage avec Mojo est impressionnante. Mais tant que ce ne sera pas open source, impossible pour moi de commencer à envisager un investissement ou une discussion sérieuse
Ce n’est pas encore prêt pour être utilisé comme langage de programmation généraliste. Modular avait aussi essayé d’appliquer l’API Mojo au moteur MAX, mais le langage évoluait trop vite, donc ils ont renoncé à investir. D’après la roadmap, une adoption sérieuse n’est à attendre qu’après l’achèvement de la phase 1
Je ne sais même pas si l’on peut vraiment dire que c’est public. Jusqu’à récemment, ce n’était pas open source, ce qui me rendait réticent à dépendre d’un logiciel propriétaire commercial
Au début de l’article, il est dit qu’on peut utiliser des « kernels de pointe ». Au final, il semble que Mojo cherche surtout à concurrencer le C++ dans le développement de kernels. Avec PyTorch ou Julia, on n’écrit généralement pas les kernels directement ; on reste surtout dans du code de plus haut niveau
Il existe plusieurs épisodes du podcast de Lex Fridman avec Chris Lattner :
La tentative Mojo elle-même est audacieuse et intéressante, mais si c’est un langage fermé à la Matlab, alors pour moi comme pour beaucoup d’autres c’est un défaut rédhibitoire majeur