Julia a résolu le problème des deux langages en rendant un langage dynamique rapide

Le calcul scientifique s'était installé dans un flux de travail à deux langages : les chercheurs prototypaient et analysaient dans un langage dynamique comme Python, MATLAB ou R, puis réécrivaient les parties lentes en C ou en Fortran. Un article d'Ars Technica de 2020 et la discussion qui s'ensuivit sur Hacker News mirent en évidence le coût de cette couture : la couche de script ne peut pas exprimer de hautes performances, tandis que la couche rapide est pénible à écrire et difficile à maintenir.

Le pari de Julia était de supprimer entièrement cette couture. Son compilateur utilise l'inférence de types et un JIT bâti sur LLVM pour compiler chaque fonction pour les types concrets des arguments avec lesquels elle est réellement appelée, de sorte qu'un langage dynamique, proche des mathématiques, peut s'exécuter à une vitesse proche de celle d'un C bien écrit. Le dispatch multiple — choisir une méthode en fonction de tous les types d'arguments plutôt que d'un seul récepteur — permet aux paquets d'étendre les fonctions génériques les uns des autres, ce qui fait que des bibliothèques indépendantes se composent au lieu que chacune enveloppe son propre cœur en C.

En 2020, la conception produisait des résultats en production, et pas seulement des benchmarks. RelationalAI déclarait que sa base de données de graphe de connaissances dans le cloud était écrite à 100 % en Julia ; la plateforme de modélisation Pumas était livrée à des entreprises pharmaceutiques et utilisée dans des soumissions à la FDA ; et des commentateurs citaient des écosystèmes entiers, des équations différentielles à l'optimisation mathématique, où les bibliothèques Julia étaient devenues les meilleures de leur catégorie. La version 1.5 était la version courante, et les développeurs du cœur soutenaient qu'il n'y avait pas eu de véritable rupture de compatibilité depuis la 1.0.

Les critiques eurent aussi leur mot à dire : lenteur des premiers tracés et latence au démarrage, outillage immature et moins de bibliothèques éprouvées que Python. Les défenseurs répondaient que le développement itératif avec Revise.jl, plus la possibilité de corriger un point chaud avec une seule nouvelle méthode, signifiaient que le même code servait à la fois à l'exploration et à la production — ce qui était précisément l'objectif de la conception.

Faire en sorte que le langage dynamique lui-même se compile à une vitesse native

L'inférence de types plus la spécialisation JIT rendent le code générique et expressif rapide sans que le programmeur change de dialecte pour les chemins critiques.

Le dispatch multiple permet aux paquets d'ajouter des méthodes aux fonctions d'autres paquets, de sorte que des écosystèmes comme les solveurs d'EDO et l'optimisation se composent au lieu de dupliquer les cœurs en C les uns des autres.

Les scientifiques conservent le modèle mental de leur problème au lieu de le remodeler d'abord pour l'adapter à un paradigme de performance, ce qui élimine toute une classe de bogues de réécriture.

Une seule base de code sert à l'exploration et à la production, de sorte que le prototype ne peut pas diverger du système qui s'exécute réellement.

Pour supprimer une étape de réécriture, ne construisez pas un meilleur pont entre deux langages ; construisez un seul langage dont la couche expressive est aussi sa couche de production.

L'article d'Ars Technica parut en octobre 2020 et son fil Hacker News recueillit 284 points avec 212 commentaires, les développeurs de Julia eux-mêmes participant au débat. La justification de la conception avait déjà été exposée par ses auteurs dans l'article de 2018 « Julia: Dynamism and Performance Reconciled by Design », et le fil de 2020 montrait des déploiements chez RelationalAI et dans la modélisation pharmaceutique, et pas seulement des prototypes de recherche. Les compromis nommés dans le fil — latence au démarrage, maturité de l'outillage et couverture des bibliothèques — restaient à l'ordre du jour de l'écosystème.