Quelle est la maturité du projet de langage informatique «Julia»?

J'envisage d'apprendre un nouveau langage à utiliser pour les projets de modélisation numérique / de simulation, en remplacement (partiel) du C ++ et du Python que j'utilise actuellement. Je suis tombé sur Julia , ce qui semble être parfait. S'il fait tout ce qu'il dit, je pourrais l'utiliser pour remplacer C ++ et Python dans tous mes projets, car il peut accéder à un code de bibliothèque de calcul scientifique de haut niveau (y compris PyPlot) et exécuter des boucles à une vitesse similaire à C. Je bénéficierais également de choses comme des coroutines appropriées qui n'existent dans aucune des autres langues.

Cependant, il s’agit d’un projet relativement nouveau, actuellement en version 0.x, et j’ai trouvé plusieurs avertissements (publiés à différentes dates dans le passé) indiquant qu’il n’était pas encore prêt pour une utilisation quotidienne. Par conséquent, je voudrais des informations sur l'état d'avancement du projet (février 2014, ou chaque fois qu'une réponse est publiée), afin de m'aider à évaluer si je devrais personnellement investir du temps pour apprendre cette langue à ce stade.

J'apprécierais des réponses qui se concentrent sur des faits spécifiques concernant le projet Julia ; Je suis moins intéressé par les opinions basées sur l'expérience avec d'autres projets.

En particulier, un commentaire de Geoff Oxberry suggère que l'API Julia est toujours dans un état de mutation, nécessitant que le code soit mis à jour lorsqu'il change. J'aimerais avoir une idée de la mesure dans laquelle c'est le cas: quels domaines de l'API sont stables et lesquels sont susceptibles de changer?

En général, je suppose que je ferais principalement de l’algèbre linéaire (résolution de problèmes propres, par exemple), d’intégration numérique des ODE avec de nombreuses variables et de tracés à l’aide de PyPlot et / ou d’OpenGL, ainsi que de la compression de nombres de style C de bas niveau (par exemple, pour les simulations Monte Carlo ). Le système de bibliothèque de Julia est-il complètement développé dans ces domaines? En particulier, l’API est-il plus ou moins stable pour ces types d’activités ou verrais-je que mon ancien code aurait tendance à casser après la mise à niveau vers une nouvelle version de Julia?

Enfin, y a-t-il d’autres problèmes qui mériteraient d’être pris en compte pour décider d’utiliser Julia pour un travail sérieux à l’heure actuelle?

Julia, à ce stade (mai 2019, Julia v1.1 dont la v1.2 est sur le point de sortir) est assez mature pour le calcul scientifique. La version 1.0 signifiait la fin des ruptures de code annuelles . Avec cela, beaucoup de bibliothèques informatiques scientifiques ont eu le temps de simplement se développer sans interruption. Un large aperçu des paquets de Julia peut être trouvé à pkg.julialang.org .

Pour le calcul scientifique de base, la bibliothèque DifferentialEquations.jl pour les équations différentielles (ODE, SDE, DAE, DDE, simulations de Gillespie, etc.), Flux.jl pour les réseaux de neurones et la bibliothèque JuMP pour la programmation mathématique (optimisation: linéaire, quadratique, mixte, etc.) sont trois des pierres angulaires de l’écosystème de l’informatique scientifique. La bibliothèque d'équations différentielles en particulier est beaucoup plus développé que ce que vous verriez dans d' autres langues, avec une grande équipe de développement mise en œuvre de fonctionnalités telles que les intégrateurs EPIRK , Runge-Kutta-Nystrom , équation différentielle Stiff / retard différentiel-Algébrique etLes intégrateurs d’ équations différentielles stochastiques rigides adaptables au temps , ainsi que de nombreux autres avantages tels que l’ analyse de sensibilité adjointe , les DSL à réaction chimique , la matrice de Newton-Krylov sans matrice et la compatibilité GPU complète (sans transfert de données), avec la formation aux équations différentielles neuronales , le tout avec résultats de référence fantastiques (disclaimer: je suis le développeur principal).

Ce qui est un peu ahurissant à propos de l’écosystème mûr de Julia, c’est sa composition. Essentiellement, lorsque quelqu'un crée une fonction de bibliothèque générique comme celle de DifferentialEquations.jl, vous pouvez utiliser n'importe quel type AbstractArray / Number pour générer du nouveau code à la volée. Ainsi, par exemple, il existe une bibliothèque pour la propagation des erreurs ( Measurements.jl ). Lorsque vous la collez dans le solveur ODE, elle compile automatiquement une nouvelle version du solveur ODE qui effectue la propagation des erreurs sans échantillonnage de paramètres . De ce fait, il est possible que certaines fonctionnalités ne soient pas documentées car le code de ces fonctionnalités est généré automatiquement. Vous devez donc réfléchir davantage à la composition de la bibliothèque.

L'algèbre linéaire est l'un des domaines où la composition est la plus utile. Les solveurs ODE, par exemple, vous permettent de spécifier jac_prototype, vous permettant de lui donner le type du jacobien qui sera utilisé en interne. Bien sûr, il existe des éléments dans la bibliothèque standard LineraAlgebra tels Symmetricque Tridiagonalvous pouvez les utiliser ici, mais étant donné l’utilité de la composibilité dans les algorithmes de type générique, les utilisateurs n’ont désormais plus créé de bibliothèques de types de tableaux. BandedMatrices.jl et BlockBandedMatrices.jl sont des bibliothèques qui définissent des types de matrices à bandes (Block) avec des lusurcharges rapides , ce qui en fait un moyen agréable d’accélérer la solution des discrétisations MOL rigides de systèmes d’équations aux dérivées partielles. PDMats.jlpermet la spécification de matrices définies positives. Elemental.jl vous permet de définir un jacobien distribué et fragmenté. CuArrays.jl définit les tableaux sur le GPU. Etc.

Ensuite, vous avez tous vos types de numéro. Unitful.jl vérifie les unités au moment de la compilation, c'est donc une bibliothèque d'unités sans surcoût. DoubleFloats.jl est une bibliothèque rapide de haute précision, avec Quadmath.jl et ArbFloats.jl . ForwardDiff.jl est une bibliothèque pour la différenciation automatique en mode avant qui utilise l'arithmétique à deux chiffres. Et je peux continuer à les lister. Et oui, vous pouvez les jeter dans des bibliothèques Julia suffisamment génériques, telles que DifferentialEquations.jl, pour compiler une version spécialement optimisée pour ces types de nombres. Même quelque chose comme ApproxFun.jlqui fonctionne comme des objets algébriques (comme Chebfun) fonctionne avec ce système générique, permettant de spécifier des PDE comme ODE sur des scalaires dans un espace fonctionnel.

Compte tenu des avantages de la composibilité et de la manière dont les types peuvent être utilisés pour générer un code nouveau et efficace sur les fonctions génériques de Julia, de nombreux efforts ont été déployés pour intégrer la mise en œuvre des fonctionnalités de calcul scientifique de base à Julia. Optim.jl pour l'optimisation non linéaire, NLsolve.jl pour la résolution de systèmes non linéaires, IterativeSolvers.jl pour les solveurs itératifs de systèmes linéaires et de systèmes de systèmes électroniques, BlackBoxOptim.jl pour l'optimisation par boîte noire, etc. Même la bibliothèque de réseaux neuronaux Flux.jl utilise simplement CuArrays. La compilation automatique de code par jl sur le GPU pour ses capacités de GPU. Cette composibilité était au cœur de ce qui créait des choses comme les équations différentielles neurales dans DiffEqFlux.jl. Les langages de programmation probabilistes tels que Turing.jl sont également bien matures et utilisent les mêmes outils sous-jacents.

Étant donné que les bibliothèques de Julia reposent fondamentalement sur des outils de génération de code, il ne faut pas s'étonner qu'il y ait beaucoup d'outils autour de la génération de code. Le système de diffusion de Julia génère des noyaux fusionnés à la volée qui sont surchargés par des types de matrice pour donner un grand nombre des fonctionnalités mentionnées ci-dessus. CUDAnative.jl permet de compiler le code de Julia dans les noyaux GPU. ModelingToolkit.jl convertit automatiquement les AST en un système symbolique de transformation du code mathématique. Cassette.jlvous permet de "superposer" la fonction existante de quelqu'un d'autre, en utilisant des règles pour modifier sa fonction avant la compilation (par exemple: modifier toutes ses allocations de tableau en attributions de tableau statiques et déplacer des opérations vers le GPU). C'est un outil plus avancé (je ne m'attends pas à ce que tout le monde en informatique scientifique prenne le contrôle direct du compilateur), mais c'est ainsi que sont construits une grande partie de l'outillage de la prochaine génération (ou plutôt, comment les entités écrivent elles-mêmes).

En ce qui concerne le parallélisme, j'ai mentionné les GPU, et Julia a le multithreading intégré et l'informatique distribuée . Le multithreading de Julia utilisera très bientôt une architecture PARTR (tâches parallèles) qui permet la planification automatisée du multithreading imbriqué . Si vous souhaitez utiliser MPI, vous pouvez simplement utiliser MPI.jl . Et bien sûr, le moyen le plus simple de tirer parti de tout cela consiste simplement à utiliser une configuration de type AbstractArray pour utiliser le parallélisme dans ses opérations.

Julia possède également l'écosystème sous-jacent de base d'un langage à usage général utilisé pour des applications scientifiques. Il a l' EDI Juno avec un débogueur intégré avec des points d'arrêt , il a Plots.jl pour faire toutes sortes de tracés. De nombreux outils spécifiques sont également utiles , comme Revise.jl met automatiquement à jour vos fonctions / bibliothèque lors de la sauvegarde d’un fichier. Vous avez votre DataFrames.jl , vos bibliothèques de statistiques , etc. L’une des bibliothèques les plus agréables est Distributions.jl, qui vous permet d’écrire des algorithmes génériques pour la distribution (par exemple:rand(dist)prend un nombre aléatoire de la distribution qui a été passée), et il y a tout un tas de distributions univariées et multivariées (et bien sûr, la distribution a lieu au moment de la compilation, ce qui rend tout cela aussi rapide que le codage en dur d’une fonction spécifique à la distribution). Il existe de nombreux outils de traitement de données , serveurs Web , etc. À ce stade, il est suffisamment mature pour que s’il existe un élément scientifique de base et que vous vous attendiez à ce qu’il existe, il vous suffit de le rechercher dans le fichier .jl ou Julia.

Ensuite, il y a quelques choses à garder à l'esprit à l'horizon. PackageCompiler cherche à créer des fichiers binaires à partir de bibliothèques Julia. Il a déjà eu quelques succès, mais nécessite davantage de développement. Makie.jl est une bibliothèque complète pour le traçage avec interactivité accélérée par GPU. Il reste encore du travail à faire, mais elle cherche vraiment à devenir la principale bibliothèque de traçage de Julia. Zygote.jl est une bibliothèque de différenciation automatique source à source qui ne présente pas les problèmes de performances d'une AD basée sur le traçage (Tracker, PyTorch, Jax), et qui cherche à fonctionner avec tous les codes purs de Julia. Etc.

En conclusion, vous pouvez trouver beaucoup de mouvement dans beaucoup d'endroits, mais dans la plupart des endroits, il existe déjà une bibliothèque solide et mûrie. Ce n'est plus à un endroit où vous demandez "sera-t-il adopté?": Julia a été adoptée par suffisamment de personnes (des millions de téléchargements) pour rester sur la lancée. Il a une communauté vraiment sympa, donc si vous voulez juste prendre des clichés et parler de calcul parallèle ou d'équations différentielles numériques, quelques-unes des meilleures salles de discussion à ce sujet figurent dans le Julialang Slack . Savoir si c'est une langue que vous devriez apprendre est une question personnelle, et si c'est la bonne langue pour votre projet, c'est une question technique, et celles-ci sont différentes. Mais est-ce un langage qui a mûri et qui est soutenu par un grand groupe cohérent de développeurs? Cela semble être un oui affirmatif.

Sinon, est-il possible de donner une estimation approximative de l'ordre de grandeur pendant combien de temps je devrais attendre avant de l'examiner à nouveau?

Mon estimation approximative, par ordre de grandeur, de la durée nécessaire au développement des langages scientifiques informatiques est d'environ 10 ans.

Exemple 1: SciPy a débuté en 2001 environ. En 2009, Scipy 0.7.0 est sorti, et l’intégrateur ODE avait une interface avec VODE (ce qui équivaut à ode15speu près à ce qui ode15sest basé sur NDF, VODE est BDF / Adams-Bashforth, selon). Avec SciPy 0.10.0, une interface dopri5, qui est à peu près équivalente à celle de MATLAB ode45, une méthode de 4ème ordre de Runge-Kutta, généralement introduite en tant que première méthode d'intégration numérique pratique pour les étudiants de premier cycle. SciPy 0.10.0 est sorti en décembre 2011, et il a fallu environ 10 ans pour qu'ils intègrent une fonctionnalité de MATLAB présentée à tous les étudiants en ingénierie que je connais.

Exemple 2: Mathworks a été fondé en 1984. Dans leur première version, ils utilisaient un port LAPACK pour C nommé JACKPAC (du nom de Jack Little, un ingénieur de MathWorks qui l’a écrit). Ils ne l'ont pas remplacé par LAPACK avant 2000.

Julia peut prendre moins de temps, mais j’estimerais qu’il faudrait environ 10 ans à partir de la fondation pour devenir un courant dominant. (Cela fait déjà environ un an; peut-être 9 à 10 ans, alors?)

Le système de bibliothèque de Julia est-il complètement développé dans ces domaines? En particulier, l’API est-il plus ou moins stable pour ces types d’activités ou verrais-je que mon ancien code aurait tendance à casser après la mise à niveau vers une nouvelle version de Julia?

Je n'utilise pas Julia, alors prenez ce que je dis avec un grain de sel, car je n'ai vu que Jeff Bezanson faire des présentations sur Julia. Ils ont fait tout leur possible pour faciliter la liaison et l'utilisation de bibliothèques de C, Python et Fortran. Si vous ne pouvez pas trouver une bibliothèque Julia qui fasse ce que vous voulez, écrivez un Julia Shim pour une bibliothèque dans une langue mieux établie. Par conséquent, je ne pense pas que le manque de bibliothèques sera un problème. Je pense qu'une des préoccupations sera de s'assurer que les modifications apportées aux fonctionnalités de base du langage ne vous mordront pas dans le cul. Si vous regardez les jalons dans le dépôt Julia Git, vous verrez que la balise "break" est assez utilisée (12 fois dans la version 0.2, 5 fois dans la version 0.3). Pour moi, cela suggère que le langage de base est en train d'évoluer, c'est pourquoi j'hésite à l'utiliser tout de suite.

EDIT: Aurelius soulève un bon point:

Qu'est-ce qui vous fait supposer que Julia deviendra un jour un grand public et ne mourra pas dans l'obscurité comme dans tant d'autres langues? SciPy / numpy avait / avait le soutien d'une communauté de python en croissance constante, ce que Julia n'a pas.

Dans la réponse initiale, j'ai décidé d'éviter la question "Julia réussira-t-elle à s'intégrer?" autant que possible. Échouer est facile; le succès est difficile. Je pense que la meilleure comparaison de Julia concerne les langages informatiques techniques tels que MATLAB, R et Octave. Les langages HPC (Chapel, Fortress, UPC, etc.) ont un public plus restreint que les langages informatiques techniques, et les langages à usage général (C, Python, C ++, etc.) ont un public plus large que les langages informatiques techniques.

Je pense que quelque chose qui aide Julia est la conception pour la performance sans sacrifier l'expressivité. Julia est beaucoup plus compétitive avec les langages compilés comme C que MATLAB, R ou même Python. Cet objectif de conception est également une fonctionnalité qui permet de tirer les personnes des langues existantes, telles que:

• Les gens qui s’intéressent beaucoup à la performance et qui viennent de langages comme C et Fortran, mais qui sont prêts à sacrifier un tout petit peu de performance (peut-être un facteur 2) pour passer du langage compilé à moins de lignes de langage interprété (avec un REPL pour développement et tests plus rapides).
• Les personnes soucieuses de productivité élevée et issues de langages tels que Python, R et MATLAB, souhaitent davantage de performances. En ce qui concerne l'exécution, Python pur, MATLAB pur et R pur sont lents. Les développeurs de ces langages ont fait de leur mieux pour envelopper les bibliothèques dans des langages compilés, mais vous ne pouvez pas tout envelopper, et à un moment donné, le langage de base va vous ralentir. Core Julia est plus rapide, ce qui vous permet de faire plus de science plus rapidement.
• Les gens qui s’intéressent au logiciel libre. Julia est interprétée et libre (de même que Python, Octave, etc.); MATLAB n'est pas.

Julia tente également de faciliter le parallélisme; Je ne me sens pas très qualifié pour développer ce point, et je ne pense pas que ce soit le tirage au sort principal du langage, mais je pense que c'est un argument de vente sur lequel ils travaillent, et j'espère que d'autres pourront l'éclairer.

Cependant, même avec un mérite technique de leur côté, les créateurs de langue doivent faire les démarches nécessaires pour promouvoir la langue et évangéliser. Jeff Bezanson, Alan Edelman, Stephen Karpinski et Viral Shah travaillent très fort pour que la langue réussisse. Alan Edelman a des liens étroits avec la communauté scientifique informatique et a déjà travaillé sur des projets linguistiques (notamment l'extension Star-P de MATLAB). Jeff Bezanson est en train de faire le circuit de conférences pour promouvoir Julia auprès des scientifiques et ingénieurs en informatique depuis un certain temps. Au MIT, ils ont fait du bon travail en recrutant des étudiants et du personnel (notamment Steven G. Johnson) pour contribuer en ajoutant des bibliothèques à Julia. Ils ont un article dans Wired et ont réussi à se faire un article sur Wikipédia, le tout après seulement un an. Leur repo Git a des milliers d'étoiles, des centaines de fourches, et des centaines de montres, donc selon les standards open source, leur projet a été un succès. Je pense qu’ils ont fait tout ce qui était bien jusqu’à présent. C’est donc une question de maintien de cet effort et de renforcement de la communauté. Ils pourraient toujours échouer, mais aller aussi loin me laisse penser qu'ils ont une chance raisonnable de réussir.

Je crois que Julia vaut la peine d'apprendre. Je l'ai utilisé pour produire quelques codes de recherche d'éléments finis et pour les produire très rapidement. J'ai été très satisfait de mon expérience.

Julia m'a permis de créer un flux de travail que j'ai trouvé difficile à réaliser avec d'autres langues. Vous pouvez l'utiliser comme langage de prototypage comme MATLAB, mais contrairement à MATLAB lorsque vous avez un code fonctionnel et que vous effectuez des itérations de profilage pour l'accélérer, le remplacement des zones réactives par du code C est simple. Ils ont fait de l’interfaçage avec C (et Python) une priorité dans la conception.

Ainsi, le langage m'a permis de passer très rapidement de mes formulations mathématiques au code fonctionnel, puis du code fonctionnel au code hautement performant. Je pense que cette fonctionnalité de Julia est sous-vendue, mais elle ajoute une valeur considérable.

Dans de nombreux cas, j'ai obtenu des performances C (comparées à mon propre code C) en quelques heures après la production d'un code d'éléments finis fonctionnels. Jusqu'à présent, si j'utilise uniquement les fonctionnalités de Julia, j'arrive généralement à ~ 3 fois plus lentement que C. Ensuite, je remplace les points chauds par des fonctions C (Julia est livrée avec un profileur d'échantillonnage de pile pour aider à les identifier). Souvent, cela nécessite uniquement de remplacer les lignes de code de points chauds offensants par un "ccall", Julia gérant tout ordre.

Je pense que la principale chose qui manque à Julia pour le moment, ce qui me fait hésiter à envisager des projets plus importants, c’est l’absence d’un débogueur entièrement pris en charge et un support médiocre pour le traçage (pour l’instant, votre meilleur pari est de n’être qu’une interface dans matplotlib que j'ai eu la pause plus souvent). Les retours immédiats sur le code sont vraiment importants. De plus, je ne sais pas comment survivre sans un débogage interactif, et MATLAB et GDB me gâtent beaucoup.

D'après mon expérience, Julia n'est pas encore prête pour un usage (scientifique) quotidien (je parle de la version stabilisée 0.4 de mars 2016). La langue elle-même est agréable, riche en fonctionnalités et cohérente; une avancée rafraîchissante de matlab et de python. Il existe certainement des cas d'utilisation où Julia est un bon choix, même à ce stade précoce. Mais si vous avez besoin de bibliothèques scientifiques fiables et matures, je ne peux pas vous recommander de déménager maintenant. Les principaux problèmes rencontrés sont:

• Les paquets en dehors du noyau de Julia ne sont pas fiables. Ils rompent avec les mises à jour, changent, se font remplacer, sont parfois incomplets ou simplement cassés.
• Les caractéristiques de parallélisme de Julia (parmi les plus prometteuses pour tuer le matlab) sont immatures. Vous rencontrerez des erreurs de segmentation, des fuites de mémoire, des pannes et des performances décevantes. Parfois, ils ne fonctionnent pas bien avec d’autres parties de julia, par exemple certains des solveurs de systèmes linéaires ou de paquetages extérieurs au noyau. Bien que ces fonctionnalités semblent prometteuses, elles ont assez souvent échoué pour moi. Presque jamais, il n’a suffi d’écrire simplement @paralleldevant la boucle, là où, théoriquement, il le devrait.
• Beaucoup de petites choses, petits bugs et problèmes avec lesquels on pourrait vivre: traces de pile d’appel pas très sympas et parfois erronées, un peu d’historique d’interprètes bogué, chargement lent des packages, mauvaise performance de l’un ou de l’autre des packages / fonctions, etc. la plupart sont le paquet PyPlot, un wrapper pour matplotlib, il n’existe actuellement aucune alternative. C'est vraiment génial que ce soit là et ça marche surtout. Mais si vous devez tracer des données, préparez-vous à des performances et à des problèmes très lents.

Tout ira mieux. Je suis convaincu qu’un jour, julia sera supérieure à matlab et python dans presque tous ses aspects. Il y a de fortes chances que des packages innovants soient développés pour cela. Il semble qu'il y ait déjà une grande communauté. Même maintenant, il existe une multitude de packages avec des cas d'utilisation allant de opencl aux serveurs Web. Utiliser python ou des bibliothèques c est très facile, vous ne risquez donc pas de vous heurter à un mur en termes de disponibilité des bibliothèques. Une grande force de Julia sera la facilité avec laquelle on peut coller des fonctionnalités de haute performance provenant de diverses sources dans un langage moderne et cohérent de haut niveau (voir les réponses ci-dessus). Mais dans l’ensemble, j’ai trouvé qu’il n’était ni assez mature ni suffisamment stable pour être utilisé de manière productive.