Mojo 🔥, le nouveau langage de Chris Lattner, est disponible sur macOS
Chris Lattner adore manifestement créer de nouveaux langages de développement. C’est lui qui a créé Swift au sein d’Apple, le développeur a quitté la Pomme et après une tentative ratée chez Tesla, il a été embauché par Google où il a adapté Swift à TensorFlow, avant de quitter l’entreprise puis… Swift lui-même. C’était en février 2022 et cette décision semblait liée autant à la culture du secret d’Apple qui colle mal avec son désir de développer en public et des décisions qui ne lui convenaient pas. Il avait peut-être déjà en tête Mojo 🔥1, son nouveau langage de développement qui est désormais disponible sur macOS.
Mojo a les mêmes ambitions que Swift, à savoir être un langage de développement universel, qui peut servir autant à écrire des scripts que du code bas niveau. Son concept de base est de combiner la souplesse de Python, avec les performances de C, soit deux autres langages de développement respectivement de haut et bas niveau. Ses objectifs le rapprochent davantage de Rust ou même de C++ que de Swift toutefois, avec en plus un accès complet à Python. On peut ainsi écrire du code en Python 3 et l’utiliser avec des programmes entièrement écrits dans ce langage, mais il est aussi possible de les convertir en grande partie en Mojo.
Pourquoi faire ? Améliorer les performances est peut-être la promesse initiale la plus importante de Mojo. L’un des exemples fournis par ses concepteurs permet de mesurer le gain de performance pour un même code, exécuté en Python et en Mojo et la différence est impressionnante. Sur mon Mac Studio M1 de base, le nouveau langage est 76 892 fois plus rapide. Il faut dire que Python ne gère pas les tâches en parallèle, alors que ce nouveau-venu est entièrement optimisé pour cela et il peut ainsi exploiter tous les cœurs de mon ordinateur pour offrir ces résultats incomparables.
Le choix de Python ne doit rien au hasard : ce langage de développement est couramment utilisé dans le domaine de l’intelligence artificielle, un domaine qui intéresse tout particulièrement Mojo. Même si le nouveau-venu entend répondre à tous les besoins, il met l’accent sur l’IA et sert de fondations au moteur de Modular, l’entreprise derrière cette initiative. Il s’agit avant tout d’offrir aux spécialistes du domaine une solution plus rapide pour entraîner et exploiter des modèles construits sur les apprentissages automatisés, avec des gains de performances notables face à PyTorch et TensorFlow.
Que ce soit votre domaine ou non, vous pouvez découvrir Mojo sur macOS et Linux, en suivant les instructions affichées sur le site officiel. Le langage de développement doit être rendu open-source à terme, mais ce n’est pas encore le cas et il faut ouvrir un compte en laissant une adresse mail pour récupérer le kit de développement.
Terminons en notant que Mojo n’est compatible nativement qu’avec les Mac Apple Silicon pour le moment. Il est toutefois possible de l’installer sur un Mac Intel, via Linux et un système de virtualisation comme Docker. Cette même méthode permet aussi de l’exploiter sous Windows, via le sous-système Linux.
-
L’emoji est utilisé non seulement pour agrémenter le nom du langage, mais aussi pour les extensions des noms de fichier. On peut ainsi créer un fichier
code.🔥et Mojo l’identifiera autant qu’un fichiercode.mojo. On n’arrête pas le progrès… ↩︎
Intéressant pour des collègues du taff !
Merci :-)
J'aurais jamais essayé de coller un emoji dans un nom de fichier, encore moins son extension... sinon le langage semble prometteur en effet :)
J’aime ces articles orientés dev sur MacG.
Mojo semble prometteur surtout s’il tient ses promesses avec Python mais avons nous vraiment besoin d’un nième nouveau langage ?
@mulot
avons nous vraiment besoin d’un nième nouveau langage ?
——-
À mon avis, L’intérêt premier d’un nouveau langage serait de faciliter l’expression d’un problème, en le présentant de la manière la plus élégante. De ce point de vue, on n’a pas finit de voir de nouveaux langages. 🤷♀️
@mulot
"mais avons nous vraiment besoin d’un nième nouveau langage ?"
Oui.
Tout nouveau langage est pensé comme alternative à un ou plusieurs autres langages, corrigeant des défauts majeurs de ces langages. Ici, la performance de Python et son aspect monothread.
Maintenant que ce langage existe, nous avons besoin d’un nouveau langage pour corriger des défauts majeurs de mojo.
Ce monsieur ferait bien d'utiliser lui même les langages qu'il développe avant de quitter le navire une fois le travail à moitié fini ou carrément pas fini comme avec Swift, en laissant les gens qu'il a convaincu se démerder.
Soit disant Swift devait être "facile" et "facile à lire".
Exemple :
guard let result = tempResult else {
return
}
C'est quoi le type de result ?
Facile me dit-on.
"Tu n'as qu'à faire un cmd-click sur result et Xcode t'affiche le type de données."
Et si tu consultes le code via un navigateur web parce qu'il fait partie d'un Pull Request, et que le code où est défini tempResult n'est pas affiché, comment fais-tu ?
Et bien tu cherches.
Alors qu'en C, C++ ou Obj-C on est obligé de déclarer le type, et tout est clair.
Juste juste exemple.
Sans parler des variables $0 et toutes les possibilités "géniales" de faire du code hyper compact, mais parfaitement illisible pour qui découvre le code d'un collègue, ce qui oblige encore une fois à faire des recherches juste pour comprendre le code qu'on lit.
Question "maintenabilité", bonjour les dégâts.
Quant à l'interoperabilité avec le C, c'est hyper verbeux et compliqué pour rien.
Là à l'inverse, il faut déclarer et redéclarer "unsafepointer" truc machin, et ça n'apporte strictement rien en terme de "sécurité".
Sans parler de l'OOP, où Xcode 15 ne peut même plus afficher de vue globale sur la hiérarchie des objets définis dans le projet. On ne peut désormais que faire des recherches, genre "affiche les classes filles" et on a une vue morcelée. Quand on doit faire du refactoring, revoir l'architecture, ça n'aide pas vraiment.
Et aussi les "categories". Avec Obj-C, c'était un peu le pendant des implementations" de Java qui sont des contrats. En Swift, ce n'est pas que ça, ça permet aussi désormais de définir du code - j'imagine pour pallier au manque d'héritage des structs favorisés au détriment des classes.
etc, etc.
@marc_os
je partage
@marc_os
Il y a des fois que je me demande si c’est pas plus XCode qui manque de fonction et de stabilité que le langage lui-même.
Bien souvent, je préfère déclarer le type ou le laisser dans le nom dans la variable.
@marc_os
Est-ce de sa faute? Peut-être que c’est une des raisons de son départ..
@marc_os
Mouais pas trop d’accord, la plupart des « défauts » que vous citez sont de la responsabilité du développeur, c’est du cas par cas.
Généralement, « ma » règle, c’est de ne pas déclarer explicitement le type si j’estime que le nom de la variable est suffisamment parlant. Pareil pour les blocks avec des $0, ça dépend des cas, parfois j’utilise la notation courte si c’est assez évident, parfois je prends la peine de donner un nom plus explicite aux variables.
Exemple con :
let shortNames = names.filter( { $0.count < 5 } )
Pas besoin de sortir de Stanford pour deviner que names est très probablement une collection de Strings, et pas besoin de nommer explicitement la variable dans la lambda, ça reste tout à fait parlant et beaucoup moins verbeux que de tout typer et déclarer explicitement.
Y a d’autres cas où c’est évidemment l’inverse qu’il faut faire. Après on est d’accord, le langage est permissif et repose sur le bon sens de la personne qui écrit le code, et pour le coup c’est une qualité qui se perd.
@ Rez2a
Le problème c'est que le langage a été vendu comme étant "facile".
Or cette facilité dépend du bon vouloir du développeur.
Or dans ma boite, la tendance générale est d'écrire du code le plus court possible.
Donc les types de variables ne sont définis de manière explicite que quand c'est nécessaire.
De plus, on code "en anglais".
Or en anglais, dans un mot composé, en général l'ordre des mots est inversé par rapport au français.
Donc par exemple si on a une variable qu'on pourrait nommer "status de l'objet", souvent ils écrivent statusObject ce qui ne veut pas dire vraiment la même chose (ça veut dire "objet représentant un status"). Donc quand le type n'est pas précisé, bonjour la lisibilité.
@ marc_os : « Or dans ma boite, la tendance générale est d'écrire du code le plus court possible.
Donc les types de variables ne sont définis de manière explicite que quand c'est nécessaire.
De plus, on code "en anglais".
Or en anglais, dans un mot composé, en général l'ordre des mots est inversé par rapport au français.
Donc par exemple si on a une variable qu'on pourrait nommer "status de l'objet", souvent ils écrivent statusObject ce qui ne veut pas dire vraiment la même chose (ça veut dire "objet représentant un status"). Donc quand le type n'est pas précisé, bonjour la lisibilité. »
Tout ce que tu as décrit là relève de limites des développeurs concernés, qui écrivent mal leur code, et non du langage lui-même. Imposer une spécification de type systématique juste pour aider à la compréhension de noms de variables foireux, ce serait un pansement sur une jambe de bois.
@marc_os
Alors il y a une chose sur laquelle on peut être d’accord : Swift a été vendu comme étant facile à lire et écrire, mais le langage s’est considérablement complexifié au fil du temps avec ses évolutions. (Perso, je n’arrive toujours pas à vérifier la valeur d’un enum avec un if sans utiliser Google 😭)
Pour les problèmes que vous décrivez, honnêtement ça relève plus d’un souci de bon sens ou d’expérience que du langage en lui-même, ça serait certainement pareil dans n’importe quel autre langage un peu moderne.
Bien nommer ses variables / méthodes et savoir quand écrire du code concis ou au contraire le rendre un peu plus verbeux quand c’est nécessaire à la compréhension, pour moi c’est une grande partie de ce qui fait un bon développeur.
@marc_os
Bah je vois pas en quoi ton ouin ouin est propre à Swift, c’est plus ou moins la même chose dans pratiquement tous les autres languages, C++ compris.
Par exemple Python n’est carrément pas typé, Rust déduit automatiquement la plupart des types et en C++ moderne le mot clef « auto » est utilisé à tout va.
Il faut comprendre que la « simplicité » à utiliser un language et lire le code provient en grande partie du style d’écriture du développeur et des fonctionnalités de l’IDE (coloration syntaxique, informations contextuelles, etc.).
L’extension de Rust pour VSCode est une référence dans le domaine Elle est capable d’ajouter inline les informations de type de données ainsi que le nom de arguments de fonctions.
"la « simplicité » à utiliser un language et lire le code provient en grande partie du style d’écriture du développeur": aaargh! Non! Enfin bien sûr le style du développeur joue aussi, mais quand même, le langage lui-même est le premier responsable. De l'objective-C (avant qu'Apple ne le surcharge en version 2) c'est 1000 fois plus lisible que du Swift…
@jerome74
Je n’ai jamais prétendu que la lisibilité du code n’étais le fruit que du style du dev. Elle provient évidemment de la syntaxe du language mais aussi de plus en plus de l’IDE.
Tu as un exemple dans le message original de ce thread avec l’utilisation du raccourci syntaxique $0 dans les closures. C’est un choix du dev qui a un impact direct sur la lisibilité du code.
La lisibilité d’un language de programmation est très subjectif, je trouve au contraire l’Objective-C illisible !
@jerome74
"Enfin bien sûr le style du développeur joue aussi, mais quand même, le langage lui-même est le premier responsable."
Évidemment que le langage est en partie responsable, sa syntaxe étant ce qu’elle est.
Mais je ne suis pas d’accord avec ton ordre de priorité. Les conventions d’écriture dans l’entreprise sont le principal facteur à la lisibilité, et bien entendu la compréhension des structures du langage par le lecteur.
J’ai même côtoyé de la metaprogrammation en C++ et templates lisible grâce à des conventions sacrément pensées et détaillées, à comparer aux majorités des implémentations de la STL juste pour le LOL. C’est dire à quel point les conventions peuvent avoir du poids.
@marc_os
Beaucoup des critiques que tu fais s’adressent plus à Xcode ou au typage faible ou aux optionnels ou aux développeurs qu’à Swift lui-même.
Je ne dis pas que Swift n’a pas de défauts hein. D’ailleurs, je n’aime pas ce langage en général, pour le même genre de raisons que je n’aime pas C++.
Mais soyons honnêtes, Xcode est à chier. C’est le pire défaut de Swift.
Aussi il y a beaucoup de friction entre le nouveau et l’ancien, Swift étant mal adapté à l’ancien et le nouveau manquant cruellement de maturité. L’ensemble est devenu brouillon et clunky. Ce n’est pas la faute directe de Swift, mais de l’environnement en général. Les API iOS et plus encore macOS ont perdu leur élégance, les deux sont des piles de frameworks disparates et très souvent mal ficelés.
Après, on peut se poser la question de la place de Swift. Qu’apporte Swift qu’aucun langage ne pourrait remplacer avantageusement ? Le poids d’Apple. Et ? Je pense : rien d’autre.
@ fte
> Mais soyons honnêtes, Xcode est à chier. C’est le pire défaut de Swift
« Soyons honnête », ce début de phrase n'annonce rien de bon.
Et la suite confirme la première impression : Il ne s'agit que de votre préjugé sans aucun argument concret.
@marc_os
"Il ne s'agit que de votre préjugé sans aucun argument concret."
Préjugé ? Postjugé en vérité, et absolument un avis subjectif. Parfaitement rapport avec le message auquel je répondais, tout aussi subjectif et très approximatif.
Dommage que tu n’ais pas lu, tu aurais vu les arguments. Quant à Xcode, il n’est pas à chier dans un cas, un seu : si on n’a jamais utilisé un IDE de qualité. Buggé, lourd, il taxe plus la batterie que JetBrains qui est pourtant en Java, éditeur primitif, fonctions de refactoring lamentables… mais je ne demande qu’à être détrompé. Ça va être sportif cependant, la plupart de ces points sont factuels et non subjectifs.
@ marc_os : « Soit disant Swift devait être "facile" et "facile à lire". »
Oui… pour les gens connaissant Swift, tout de même.
Pas pour les gens ne souhaitant que lire de l’Objective C quand ils sont face à un code en Swift — là, évidemment, ça passe moins bien. 😉
« C'est quoi le type de result ? »
Ben le même que celui de tempResult, mais non optionnel.
Et si à ce moment-là du code, tu ne connais pas le type de tempResult, c’est que tu n’as pas commencé la lecture au bon endroit ou que le code au-dessus est bien mal écrit.
« Alors qu'en C, C++ ou Obj-C on est obligé de déclarer le type, et tout est clair. »
Comme si ces langages ne permettaient pas tout autant d’écrire du code peu lisible… 🙄
« Et aussi les "categories". Avec Obj-C, c'était un peu le pendant des implementations" de Java qui sont des contrats. »
Fais gaffe, quand tu t’emportes tu mélanges tout ! 🙂
Je pense que tu voulais parler des protocoles en Objective C et Swift, et des interfaces en Java.
« En Swift, ce n'est pas que ça, ça permet aussi désormais de définir du code - j'imagine pour pallier au manque d'héritage des structs favorisés au détriment des classes. »
Il s’agit moins de pallier un manque que de restreindre volontairement l’héritage à de l’héritage de comportement. Ce qui, comme nous avons déjà eu l’occasion d’en discuter, n’empêche nullement de faire de la programmation orientée objet avec tout ça.
Et pour ceux qui ont des besoins différents (ou juste pour une question de préférence), il existe aussi les classes.
@ BeePotato
> « Et aussi les "categories". Avec Obj-C, c'était un peu le pendant des implementations" de Java qui sont des contrats. »
> Fais gaffe, quand tu t’emportes tu mélanges tout !
Tu as compris quand même, même si je me suis mélangé les pinceaux.
> Il s’agit moins de pallier un manque que de restreindre volontairement l’héritage à de l’héritage de comportement.
Il s'agit bien de palier le manque d'héritage inhérent aux structs.
Certes Swift permet encore de faire de l'POO. Mais les auteurs de Swift le déconseille car ce serait moins efficace. Et moi qui croyait que de développeur de compilateurs était un génie...
@ marc_os : « Il s'agit bien de palier le manque d'héritage inhérent aux structs. »
Ben non, comme je l’ai d’ailleurs écrit.
D’une part, le « manque d’héritage » dont tu parles n’est pas inhérent aux structs — c’est le résultat d’une décision, il n’y avait rien qui dictait que ça devrait forcément être comme ça.
Et pour accompagner cette décision de ne pas avoir dans ces types de données un héritage du stockage, il y a eu la décision d’étendre les protocoles pour avoir un héritage du comportement. Ça reste bien de l’héritage, utilisable par les structs.
« Certes Swift permet encore de faire de l'POO. Mais les auteurs de Swift le déconseille car ce serait moins efficace. »
Ce qui est conseillé, c’est d’éviter le dispatch dynamique (pour les appels de méthodes) lorsqu’on cherche le maximum de performances — ce qui est logique. Mais il y a plein de situation où la (petite) différence de performances n’est absolument pas importante et où on peut donc utiliser ce qu’on veut (ou, de préférence, ce qui est le plus adapté à la situation).
Et il est aussi conseillé de préférer autant que possible des types pensés pour un usage par valeur (les structs) plutôt que par référence (les classes), afin d’éviter certains types de bugs. Mais là aussi, c’est pour les situations où c’est adapté, et non une règle absolue imposée à tout code.
Et rien de tout ça ne s’oppose à la programmation orientée objet, qu’il serait de toute façon bien difficile d’éviter en Swift (on passe son temps à envoyer des messages à des objets ; on pourrait certes se forcer à ne pas créer de nouveaux objets pour ses propres types de données, mais ce serait artificiel, et non le résultat d’une orientation du langage).
Même la « programmation orientée protocoles », si chère à Dave Abrahams et mise en avant aux débuts de Swift, est juste une approche spécifique de la POO et donc pas en opposition avec cette dernière (malgré la façon dont il a formulé la chose à l’époque).
"Pourquoi faire ?": parce qu'on a une envie pressante?
"Pour quoi faire?": ce qu'on a envie ou besoin de faire, sûrement.
Ça marche pas avec la version native de docker sous windows ? Pourquoi devoir passer par le sous système Linux ?
@Adodane
Windows doit vraiment pas être une priorité pour eux. La cible pour l’instant c’est l’IA et donc les devs comme les serveurs qui tourneront le code ne sont majoritairement pas sous Windows.
@Adodane
C’est sur les macs Intel qu’il faut utiliser une version Linux avec Docker. Pour Windows, cela marche avec le sous-système Linux intégré à l’OS, pas besoin de Docker, et il me semble que le sous-système Linux est pleinement intégré dans le noyau Windows.
@Adodane
La version native de docker pour windows fait tourner des programmes pour windows.
Comme ce programme est développé pour unix, il faut une vm (wsl) qui fait tourner linux.
‘Reads like Python, runs like C’ :
n’a-t-on pas déjà entendu ce son de cloche, quelque part ?
Si : à propos de Julia.
D’ailleurs, c’est Chris Lattner lui-même qui explique les parallèles et les différences entre Julia et son briquet :
https://news.ycombinator.com/item?id=35791125
En tant qu’adepte de Julia, je vois avec plaisir ce nouvel outil s’ajouter à la panoplie. Mais ayant suivi de près l’évolution de Julia, je ne sous-estime pas le chemin qui reste à parcourir pour que MojoLaFlamme parvienne à maturité.
Je ne suis pas dev, mais... Peut-on faire une app accessible avec VoiceOver avec ce langage?
@math65
C’est vraiment pas le but, je ne sais même si on peut faire une App à proprement parler avec ce langage (dans le sens avec une UI, etc…).
Moi, je trouvais Fortran, Pascal, Pascal-Objet et Modula-2 très lisibles. Après, j’ai perdu le fil…
Merci à tous les contributeurs (et contributrices ?) de ce fil. Les différents points de vue sont très intéressants.
En fait, ce mec n’aime pas bosser en équipe je crois !
le nouveau langage est 76 892 fois plus rapide......cela laisse sans voix😁
"... faut dire que Python ne gère pas les tâches en parallèle ..." sauf si on utilise multiprocessing ou le threading, c'est dans la documentation, ça s'appelle le parallélisme https://docs.python.org/fr/3/library/multiprocessing.html et ça ne date pas d'hier ;-)
L’un des exemples fournis par ses concepteurs permet de mesurer le gain de performance pour un même code, exécuté en Python et en Mojo et la différence est impressionnante. Sur mon Mac Studio M1 de base, le nouveau langage est 76 892 fois plus rapide. Il faut dire que Python ne gère pas les tâches en parallèle.
Comparer les performances avec Python c'est juste ridicule.
Faites la comparaison avec du code en C, C++ ou Objective-C utilisant correctement libdispatch, et le résultat risque d'être fort différent.
@marc_os
"Faites la comparaison avec du code en C, C++ ou Objective-C utilisant correctement libdispatch, et le résultat risque d'être fort différent."
La comparaison n’a rien de ridicule puisque Mojo vise en particulier les utilisateurs de Python et à pallier à certains défauts de Python.
Mais c’est juste que de comparer avec des langages compilés donnerait des résultats différents.
Python est connu pour être inefficace donc le parallèle n'est pas si parlant que cela. Et l'intérêt d'un nouveau langage est souvent présent. Par contre, développé par un seul gars, il risque d'y avoir des bugs pendant longtemps...
@ koko256
Mais que craignez vous ?
Tout le monde vous dira que Chris Lattner est un génie.
Et on peut compter sur lui sur le long terme.
Ou pas (cf. Swift).