Warning: closed-source et tout jeune ¶

Avant d’aborder les discussions sur les langages de programmation et Mojo, deux aspects cruciaux méritent notre attention.

Tout d’abord, il est essentiel de noter que Mojo est actuellement un projet à code source fermé sous la direction de la société Modular . Cette société est spécialisée dans l’intelligence artificielle (IA) et prévoit d’améliorer significativement le cadre technologique dans ce domaine. Les éléments constitutifs de cette stratégie sont (i) un nouveau moteur d’IA nommé MAX (quelque chose comme TensorFlow et PyTorch, mais d’une certaine manière compatible avec ces solutions) et (ii) un nouveau langage de programmation - Mojo. Bien que Modular affirme que Mojo n’est pas destiné à être un “produit” commercial et qu’ils écrivent qu’ils “prévoient de rendre progressivement Mojo open-source” [ 1 ] , le projet reste fermé à l’heure actuelle. Nous reviendrons plus loin sur cet aspect critique.

Deuxièmement, il est important de reconnaître que Mojo en est encore à ses débuts et, à mon avis, qu’il n’est pas encore prêt à être utilisé en dehors de Modular. Les créateurs de Mojo se sont concentrés sur le cœur du langage et sur les performances.

Lancer un nouveau language de programmation ¶

Alors que des vieux langages de programmation comme Python, C, C++, Java ou Javascript continuent de dominer le paysage [ 2 ] [ 3 ] , le domaine de la recherche appliquée aux langages de programmation a connu une activité remarquable ces dernières années. Une vague d’innovation a donné lieu à l’introduction de nouveaux langages de programmation (pour n’en citer que quelques-uns, Zig, Vlang, etc.). Outre ces vétérans et ces nouveaux venus, il existe également quelques langages d’âges intermédiaires (comme Go, Rust, Julia et Swift) qui ont rassemblé des communautés actives autour d’eux.

Dans cette note, nous nous concentrerons principalement sur Rust, Julia et Swift. Rust, soutenu par la Fondation Mozilla, a vu le jour en 2006 et a été présenté publiquement en 2010, apportant des innovations notables par rapport au C++, en particulier en matière de sécurité avec son vérificateur d’emprunts (“borrow checker”). Ce langage système connait un grand succès et est utilisé pour de nombreuses applications, comme par exemple dans le développement de Firefox. Malgré ses qualités, Rust est connu pour sa courbe d’apprentissage abrupte, ce qui le rend potentiellement moins adapté au prototypage rapide dans le domaine scientifique. Le développement de Julia a commencé en 2009, et le langage a été officiellement lancé en 2012 - il y a plus de dix ans. Au fil des ans, Julia a mûri et trouvé sa place pour des applications de calcul numérique intensif, où il excelle. Swift, le dernier langage d’Apple, a commencé à être développé en 2010, et la première version a été publiée en 2014. Swift est passé à un modèle open-source en 2015.

Lancer un nouveau langage de programmation en 2023 est une idée audacieuse. Dans un paysage dominé par des choix robustes et matures, la concurrence entre les langages de programmation est redoutable. Un nouveau langage doit non seulement présenter des caractéristiques et des avantages nouveaux par rapport à ses concurrents directs, mais il doit aussi être suffisamment bon en général. Les avantages liés à l’adoption d’un nouveau langage doivent l’emporter sur les coûts associés à l’utilisation d’un langage moins établi. En outre, dans ce domaine, l’aspect pratique l’emporte souvent sur la pureté. Le cas de Julia par rapport à Python est très intéressant. Julia présente des avantages évidents par rapport à Python dans le domaine du calcul scientifique, en particulier de meilleures performances et de meilleures fondations techniques, permettant d’éviter le “problème des deux langages”. Cependant, Python est suffisamment bon, présente d’autres avantages et évolue assez rapidement pour qu’il n’y ait pas de changement significatif en faveur de Julia [ 4 ] .

La création et l’établissement d’un nouveau langage de programmation est une tâche monumentale. Si des ressources considérables sont naturellement allouées à la conception du langage et au développement de son interprèteur/compilateur, il faut également prendre en compte d’autres aspects tels que la création d’une communauté, d’outils pour les développeurs et la distribution de codes, de bibliothèques, de documentation, etc.

Notons également que la création, la construction et l’évolution des languages sont des processus lents. Ces constructions humaines sont si complexes que l’échelle de temps typique est plutôt de plusieurs années que de plusieurs mois. Dans les cas de Rust, Julia ou Swift, plusieurs années se sont écoulées entre le lancement des projets et leurs premières versions publiques. L’équipe Mojo a, quant à elle, opté pour une stratégie de publication précoce, initiant rapidement la présence publique de son projet. Malgré cela, ils sont toujours dans un mode de développement rapide et fermé avec une petite équipe cohérente. Les progrès impressionnants réalisés en un peu plus d’un an suscitent la curiosité quant à la trajectoire future du projet.

Pourquoi Mojo a ses chances ¶

Pourquoi devrions-nous nous intéresser à ce tout jeune langage de programmation ? A mon humble avis, des raisons convaincantes suggèrent que Mojo pourrait émerger comme l’un des langages les plus importants dans les années à venir :

• Mojo est une réponse à un état réellement sous-optimal pour le calcul (scientifique et IA) dominé par des langages avec des faiblesses évidentes (bien sûr Python et C++, mais aussi Julia et Rust). Ce serait une nette amélioration d’avoir un nouveau langage avec un meilleur équilibre entre convivialité/performance/sécurité, avec des capacités de compilation JIT/OAT et une courbe d’apprentissage douce, en particulier pour les personnes familières avec Python.

• Mojo est fondé sur une intuition très intéressante : un langage statique et sûr avec de fortes capacités dynamiques et une intégration transparente avec Python.

• Mojo est porté par des personnes très intelligentes et renommées, en particulier Christ Lattner , le “cofondateur de LLVM, du compilateur Clang, de l’infrastructure du compilateur MLIR et du langage de programmation Swift” (extrait de sa page Wikipédia). Ses antécédents impressionnants dans des projets open-source importants et couronnés de succès ajoutent une couche substantielle de crédibilité. Bien que d’autres personnes accomplies aient contribué à la création de Mojo, le CV remarquable de Chris Lattner se distingue.

• Mojo repose sur des bases techniques très solides, LLVM et MLIR, comme nous le verrons plus loin. “Mojo est le premier langage majeur conçu expressément pour MLIR” [ 5 ] .

• Mojo semble avoir un financement solide et à long terme, soutenue par une entreprise sérieuse, avec des partenariats avec Amazon Web Services (AWS) et NVidia .

Les motivations qui ont conduit à la création de Mojo sont décrites en particulier dans la page Why Mojo . Il s’agit en grande partie de corriger la pile technologique utilisée dans l’IA, dominée en particulier par Python et C++. Cela positionne Mojo comme une nouvelle tentative de résoudre le “problème des deux langages”, ce qui a été une des motivations principales de Julia. Cependant, les approches adoptées par Julia et Mojo pour résoudre ce problème diffèrent de manière significative, à la fois en termes d’essence technologique (qui sera discutée plus tard) et dans leur relation avec Python. De manière quelque peu provocatrice, Julia et sa communauté sont perçues comme étant “contre Python”, tandis que Mojo vise à devenir un nouveau membre de la famille Python.

Lorsque Julia a été conçu en 2009, l’empreinte de Python dans le domaine du calcul scientifique était relativement modeste. Numpy n’a été introduit qu’en 2006 et Python 2.7 n’a été publié qu’en 2010. Pendant cette période, Matlab occupait une position plus dominante. Par conséquent, la conception de Julia s’est orientée vers Matlab plutôt que de s’aligner étroitement sur Python-Numpy. De plus, il n’est pas pratique d’utiliser Julia pour construire des librairies utilisables depuis Python (ou R d’ailleurs). L’approche “un langage pour tout” n’est pas très coopérative par nature. En revanche, la stratégie pragmatique consistant à utiliser des langages distincts pour des tâches différentes s’est avérée très efficace pour construire un écosystème scientifique Python robuste. Cet écosystème s’appuie sur des langages tels que C, Fortran, C++ et maintenant Rust [ 6 ] .

Bien que Julia soit formidable et dispose d’un excellent écosystème dans sa niche - le calcul numérique intensif - ce language a tendance à être quelque peu isolée. Pour la vaste communauté des utilisateurs de Python et des développeurs de librairies Python, il n’est pas très intéressant d’investir du temps dans Julia.

La stratégie alternative de Mojo concernant sa relation avec Python semble tout à fait raisonnable. L’introduction d’un langage compagnon et complémentaire pourrait trouver un accueil chaleureux au sein de la communauté Python. Compte tenu de la domination et de l’élan actuels de Python (voir la section suivante), ainsi que de l’inertie inhérente à la dynamique des langages, il s’agit d’un avantage très sérieux pour Mojo au cours de la prochaine décennie.

Projets améliorant Python ¶

Pour mieux comprendre Mojo, il est utile de préciser ce qu’il n’est pas, en explorant quelques projets visant à améliorer Python et à remédier à ses faiblesses.

• PyPy et GraalPy : Ces projets sont des implémentations alternatives de Python plus rapides que CPython. Cependant, leur adoption est limitée car ils ne peuvent pas accélérer les paquets qui reposent sur l’API C de CPython, tels que Numpy, Matplotlib, Pandas, scikit-learn, et d’autres.

• Correction de l’API C de Python : des efforts sont en cours pour résoudre cette limitation. Il s’agit notamment de l’introduction de la nouvelle API C HPy (une API C pour Python indépendante de CPython) et d’une initiative à long terme plus ambitieuse visant à améliorer l’API C de CPython .

• Développements de CPython : Les développeurs de CPython sont activement engagés dans des projets visant à améliorer les performances de CPython : no-gil, subinterpreters , et “Faster CPython”. CPython 3.13, qui sera utilisable à la fin de 2024, devrait avoir le GIL (Global Interpreter Lock) supprimée et un compilateur JIT basé sur l’approche Copy & Patch .

• Compilateurs Python : divers compilateurs Python, tels que Pythran, Numba et Mypyc, permettent d’accélérer des sous-ensembles spécifiques (statiques) de Python, certains étendant la prise en charge à Numpy.

• Calcul parallèle et avec GPU : Des projets innovants comme Codon et Taichi introduisent des “Langages Spécifiques à un Domaine” (DSL) en Python, adaptés au calcul parallèle et avec GPU.

Mojo se distingue de ces projets car il est un nouveau langage véritablement indépendant.

Mojo==Python++? En fait super different ¶

Le site web de Mojo indique que l’un des objectifs à long terme de Mojo est de devenir un surensemble de Python, ce qui signifie que la plupart des programmes Python devraient fonctionner sans modifications. Je ne suis pas très optimiste à ce sujet, mais cela ne me semble pas si important. Pour exécuter du code Python, nous avons de toute façon d’autres bons interpréteurs Python. Je considère que certaines fonctionnalités de Python ne sont pas très utiles pour un projet comme Mojo, par exemple le support du module inspect (pour l’introspection dynamique), le “monkey patching” de n’importe quoi (même les builtins du langage) ou l’API C de CPython.

Quoi qu’il en soit, il est important de réaliser que Mojo est complètement différent de Python. Il y a quelques fonctions intégrées communes ( print , len , range , slice , …) et la syntaxe est largement compatible (imports, indexation, slicing, boucles, définitions de fonctions, contexts, try / except , async / await , même la définition de struct avec des “dunder” methods, …). Comme déjà écrit, Mojo peut également être “interprété” et dispose d’un REPL (qui peut être lancée avec la commande mojo). Mais certains types Python très importants sont encore absents (comme str , int , float , list , tuple et dict ) et presque aucune bibliothèque standard Python n’est disponible. De plus, plus profondément et de manière plus importante, la sémantique du langage est très différente. Par exemple, les variables Mojo ressemblent beaucoup plus à des variables C qu’à des variables Python : un nom dans Mojo est attaché à un objet en mémoire. Par exemple,

from memory.unsafe import Pointer

def print_pointer(ptr: Pointer):
    print(ptr.__as_index())

def main():
    a = 1
    p1 = Pointer.address_of(a)
    print_pointer(p1)

    a = 2
    p2 = Pointer.address_of(a)
    print_pointer(p2)

    # a = "mojo"  # error: cannot implicitly convert 'StringLiteral' value to 'Int' in assignment

affiche

140728977102328
140728977102328

ce qui signifie qu’il n’y a qu’une seule variable entière qui a été modifiée “inplace” par l’instruction a = 2 . En revanche, le code Python équivalent, quelque chose comme,

a = 1
print(id(a))
a = 2
print(id(a))
a = "python"  # valid

affiche

140163769254128
140163769254160

de telle sorte que id(2) - id(1) soit égal à 32. Le nom (la référence) a pointe d’abord vers l’objet entier 1 . L’instruction a = 2 modifie la référence (le nom a ) et non l’objet int .

En Python, les références sont partout (les noms sont des références, les éléments d’une liste/tuple sont des références, les arguments des fonctions sont passés en tant que références). Cela ne fonctionne pas comme ça avec Mojo, ce qui a des conséquences importantes. Par exemple, en Python a = "py" ; b = a crée deux références pointant vers un seul objet ( "py" ). En revanche, a = "mojo" ; b = a crée deux objets différents à deux endroits différents en mémoire, de sorte que

b = "mojo"
p = Pointer.address_of(b)
print_pointer(p)

c = b  # <- this really copies the String object "mojo"
p = Pointer.address_of(c)
print_pointer(p)

affiche quelque chose comme

140720822767840
140720822767856

Le contraste devient évident dans ces exemples, et on voit que Mojo offre aux développeurs un engagement plus direct avec les objets en mémoire. Contrairement à Python et Julia, Mojo n’utilise pas de comptage de références (“reference counting”) ni de ramasse-miettes (“garbage collector”). Au lieu de cela, la gestion de la mémoire, définissant la “durée de vie” (“livetime”) des objets, est automatiquement gérée par un vérificateur d’emprunts (“borrow checker”), comme en Rust. Néanmoins, Mojo offre également la flexibilité d’écrire du code rappelant le C, employant des pointeurs et une allocation et désallocation explicite de la mémoire. En conclusion, il devient évident que Mojo est avant tout un nouveau langage statique s’inspirant de C++, Rust et Swift. Ce langage est conçu pour la programmation système sûr.

def modify(a):
    # argument given by copy in Mojo `def` but one can modify the referenced list
    a[0] = 1

def main():
    a = object([0])
    b = a  # <- the reference is copied but not the pointed list

    print(a)  # prints [0]
    modify(a)
    print(a)  # prints [1]
    print(b)  # prints [1]

alias PI = 3.141592653589793
alias TAU = 2 * PI
alias my_alias = my_function_executed_at_compile_time()

fn bar[a: Int](b: Int):
    print("bar[a: Int](b: Int)")

@parameter
if ...:
    ...

@parameter
fn my_closure[size: Int]():
    ...

Commentaires sur des caractéristiques actuels et futures de Mojo ¶

from python import Python

np = Python.import_module("numpy")

Que manque-t-il à Mojo pour être réellement utilisable pour le calcul scientifique ? ¶

Conclusions ¶

Comme nous l’avons exploré, l’un des aspects distinctifs de Mojo est qu’il permet(tra) aux développeurs d’écrire du code statique et sûr, à l’instar de Rust. Simultanément, Mojo supporte du code dynamique potentiellement sans annotations de typage, comme en Python. Bien que ces deux aspects soient encore en évolution et appelés à s’améliorer dans les mois/années à venir, il est crucial de reconnaître que même si Mojo vise à devenir un surensemble de Python, il ne doit pas être simplement considéré comme un “Python++”. Il est plus juste de considérer Mojo comme un nouveau langage statique moderne fortement influencé par C++, Rust et Swift, mettant l’accent sur la performance, la portabilité et la capacité d’écrire du code générique pour du matériel exotique. Ce n’est qu’ensuite qu’on peut apprécier le fait que Mojo peut aussi être interprété (avec compilation JIT) et permet d’écrire du code dynamiquement typé, ce qui lui donne le potentiel de devenir un quasi-superensemble de Python.

Nous observons que Mojo présente des similitudes et des différences significatives avec Cython, un langage qui agit comme un surensemble de Python avec des capacités C. Contrairement à Mojo, le code Cython nécessite une transpilation en C et ne peut fonctionner indépendamment d’un interpréteur Python. Cython est largement adopté dans de nombreux logiciels à succès de la pile numérique Python, tels que scipy et scikit-learn. Cependant, son utilisation reste confinée à cette application de niche. S’il devient possible de créer des extensions Python à partir du code Mojo, Mojo pourrait constituer une alternative convaincante à Cython.

La trajectoire actuelle de Mojo suggère qu’il est conçu pour un succès à long terme. Modular envisage de construire un langage de programmation puissant conçu pour prospérer au cours des prochaines décennies, en positionnant Mojo comme un concurrent face à des langages statiques établis, matures et entièrement libres. Cependant, les incertitudes entourant la future licence de l’interpréteur/compilateur Mojo, avec en particulier des composants de base restant potentiellement propriétaires, ne semblent pas compatibles avec les ambitions affichées par Modular pour Mojo.

L’équipe Mojo est en passe de livrer un langage exceptionnel pour le calcul haute performance dans les prochains mois. Compte tenu des progrès remarquables observés jusqu’à présent, il est raisonnable de penser que d’ici la fin de l’année 2024, Mojo sera techniquement robuste, avec une gestion améliorée de la durée de vie, un Enum semblable à Rust, une compatibilité avec Python, et bien d’autres choses encore.

La décision cruciale de rendre le cœur de Mojo entièrement open-source va avoir des conséquences significatives. S’il est entièrement ouvert, Mojo pourrait avoir un impact transformateur, en particulier au sein de la communauté Python. Ce scénario nécessiterait un investissement de la part de l’équipe Mojo pour permettre la génération d’extensions Python à partir du code Mojo. L’élan open-source qui en résulterait pourrait rapidement renforcer l’écosystème Mojo, en favorisant le développement de nombreuses nouvelles bibliothèques. Au contraire, si le cœur de Mojo reste partiellement fermé, l’adoption risque d’être modérée, de nombreuses personnes optant pour d’autres solutions open-source. Il est intéressant de noter que lorsque j’ai présenté Mojo à des développeurs expérimentés et hautement qualifiés, leur première réaction a souvent tourné autour de son statut de logiciel fermé et des incertitudes concernant son futur statut de logiciel libre.

J’ai tendance à être optimiste quant à la future nature open-source de Mojo parce que c’est dans l’intérêt de Mojo, et donc de Modular. Mojo est encore un oisillon en pleine croissance dans son nid closed-source. L’espoir est que, dans les années à venir, Mojo déploiera ses ailes, s’élevant aux côtés de ses grands homologues open-source dans les courants ascendants du développement collaboratif.

En conclusion, j’aimerais partager mon impression très personnelle de Mojo. En tant que développeur Python ayant de l’expérience dans les langages statiques et le calcul haute performance, l’utilisation et l’exploration de Mojo ont été à la fois agréables et stimulantes sur le plan intellectuel. J’ai eu l’impression d’être à la fois chez moi, en vacances et doté de superpouvoirs. Par contre, comme il n’est pas facile d’apprendre à conduire avec une navette spatiale, on peut se demander s’il sera bon de mettre Mojo entre toutes les mains.