Modular a sorti la 26.5 le 11 août et estampille Mojo en 1.0. Le numéro de version n'est pas la news. La news, c'est qu'écrire pour le GPU redevient un truc de développeur normal.
CUDA ou pas CUDA ?
Depuis 15 ans, programmer un GPU veut dire écrire du CUDA C++, connaître le modèle mémoire de Nvidia, et accepter que ce code ne tournera nulle part ailleurs.
Je le dis car j'ai essayé OpenCL à l'époque et c'est beaucoup moins outillé.
Mojo attaque exactement ce point : le même langage pour le CPU et le GPU, une syntaxe qui ressemble à du Python, la bibliothèque accélérateur de MAX pour la gestion des devices et des tenseurs, et la possibilité de descendre en PTX quand vous en avez vraiment besoin.
Je m'explique : le problème n'a jamais été que CUDA soit mauvais, il est excellent.
Le problème, c'est qu'il a réservé l'écriture de kernels à une caste de spécialistes, et que cette caste est le vrai goulot d'étranglement du calcul accéléré.
Et le 1.0 est ce qui rend la promesse utilisable
Un langage qui bouge tous les trois mois, vous ne le mettez pas en prod, vous le regardez.
C'est précisément ce que Modular corrige avec ce 1.0 : sur toute la branche 1.x, les changements seront majoritairement additifs. La 26.5 termine le nettoyage qui rendait le langage intimidant, en supprimant les manières multiples de dire la même chose :
- déclaration de variables uniformisée avec var
- closures unifiées et un seul type Pointer
- syntaxe lambda façon Python pour les closures inline
- serveur LSP nettement plus stable sous VS Code, ce qui change tout quand on débute
- diagnostics de sécurité mémoire sur l'invalidation de références (un append qui invalide une référence dans la liste, par exemple)
- des skills agentiques officielles couvrant justement la programmation GPU et le portage depuis d'autres langages
uv pip install --upgrade mojo
uv pip install max[all]
Donc ce qui se démocratise, c'est le coût par tâche
Aujourd'hui, quand un modèle tourne mal sur autre chose qu'une carte Nvidia, la cause est rarement le silicium.
C'est la couverture kernel, les collectives, les ops manquantes, tout ce que 10 ans de CUTLASS et de cuDNN ont accumulé en face.
Un langage portable ne réécrit pas cette dette d'un coup, mais il divise le coût d'entrée pour la réécrire, et il ouvre la porte à des cibles CPU, GPU et NPU depuis une seule base de code.
Et c'est là que ça devient une question de coût par tâche et pas de coût par token : si vous pouvez faire tourner votre inférence sur le matériel disponible plutôt que sur le matériel imposé, votre facture ne se négocie plus avec un seul fournisseur.
Mais je ne signe pas le chèque avant le 18 août
Il y a un angle mort dans cette histoire de démocratisation. La bibliothèque standard est open source (près de 200 contributeurs, plus de 1100 pull requests, 200 000 lignes touchées), le compilateur et la toolchain ne le sont pas, et Modular s'engage à les ouvrir en 2026, soit dans moins de cinq mois.
Sauf que cette promesse a été faite par une startup indépendante et qu'elle est portée depuis le 29 juillet par une filiale à 100 % de Qualcomm, avec Chris Lattner passé EVP chez le fondeur.
Un langage qui vend la neutralité matérielle et qui appartient à un vendeur de puces, ça se vérifie, ça ne se croit pas sur parole, et ce qui rendrait la chose vérifiable c'est justement l'ouverture du compilateur, possiblement annoncée à ModCon le 18 août.
Je n'ai pas encore de Mojo en production, donc je ne vais pas vous vendre un retour de terrain que je n'ai pas. Mais je vais tester le portage d'un kernel simple et vous raconter.
Ce qui m'intéresse c'est: est-ce que dans 2 ans, un dev backend lambda peut écrire un kernel GPU sans demander l'autorisation à personne.
