Le langage de programmation Julia n'est pas parmi les plus récents (les premiers travaux ont débuté en 2009). Il a été conçu, au départ, pour des tâches de programmation scientifique et parallèle.

À l'époque, l'environnement informatique était loin d'être aussi avancé. On parlait plus de Fortran ou de MATLAB (deux environnements pas forcément intuitifs ou bon marché) que de Python, langage désormais préconisé : NumPy ne fonctionnait pas encore très bien, Cython et PyPy pour l'accélération de code étaient à peine sortis en 2007 ; les solutions actuelles d'accélération de code (par compilation à la volée) sont plus récentes encore, Numba n'étant sorti qu'en 2012. Toutes ces raisons ont poussé une série de chercheurs du MIT à développer ce qui est devenu Julia. Si l'écosystème Python était plus avancé en 2009, il y a fort à parier que Julia n'aurait jamais vu le jour.

On peut donc clairement se demander pourquoi on chercherait à investir dans Julia, maintenant notamment que Python est aussi développé. Surtout que Python est le second langage d'une bonne partie des développeurs Julia ! Peut-être que, sans Julia, Python disposerait d'un lecteur de fichiers CSV aussi efficace que celui de Julia ? Ou alors les fonctionnalités de métaprogrammation et de combinaison de bibliothèques ? En tout cas, depuis 2009, bon nombre de langages se sont développés et ont pu attirer plus d'utilisateurs que Julia, avec une communauté plus grande : Swift, Go, Kotlin, Rust, par exemple.

Les utilisateurs actuels de Julia précisent que peu de facteurs techniques les empêchent d'utiliser Julia autant qu'ils le voudraient : ils sont plutôt limités par leur organisation, le peu de collègues qui ont entendu parler du langage, mais aussi par les ressources d'apprentissage disponibles.

Il n'empêche, les facteurs techniques restent très souvent discutés. Notamment, la compilation de code reste lente, ce qui fait que charger un paquet prend du temps — un problème souvent nommé "temps pour le premier graphique", ces latences étant surtout visibles pour du code d'affichage de graphiques (qui prend beaucoup de temps à compiler, sans que les optimisations effectuées aient un impact significatif sur le temps d'exécution). Heureusement, la prochaine version (1.6) améliorera fortement ce point. Selon les applications, il manque aussi certains paquets et ceux qui existent déjà sont loin d'être parfaits : dès que l'on sort des sentiers battus, le code est moins optimisé, moins bien conçu, il manque plus rapidement des fonctionnalités importantes. Au niveau du langage, certains estiment qu'il n'y a pas vraiment de fonctionnalité pour inciter à écrire du bon code, à l'instar de Python, surtout en comparaison de langages comme Rust.

Il n'empêche que certaines organisations écrivent de grandes quantités de code en Julia et ne s'en plaignent pas. Par exemple, l'équipe CLiMA de Caltech (California Institute of Technology) développe une approche révolutionnaire pour la modélisation climatique. La trentaine de paquets Julia cherche à modéliser l'évolution du climat en utilisant des techniques d'apprentissage automatique, plutôt que des approximations d'équations différentielles (l'approche prédominante jusqu'à présent). Cette approche nécessite de repartir de presque rien du tout. Julia a permis de développer extrêmement rapidement du code de qualité pour résoudre ces problèmes scientifiques. Toujours dans le domaine de la climatologie, la réécriture complète d'un solveur de Fortran vers Julia a permis d'accélérer le code d'un facteur 3, malgré les abstractions que propose Julia par rapport à Fortran.

Et vous, que pensez-vous de l'utilisation de Julia dans des applications réelles, que ce soit en production ou de grande taille (ou les deux) ? Quels sont les freins pour votre adoption de Julia ?