Julia, un langage d'avenir ?

Version imprimable

10/03/2021, 01h39
dourouc05

Julia, un langage d'avenir ?

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 ?
10/03/2021, 07h43
Bayard

Heu, mise à part https://clima.caltech.edu/, qui utilise ce langage ?
10/03/2021, 10h00
Nozio

Une liste d'industriels utilisant Julia, clients de juliacomputing peut être trouvée sur cette page : https://juliacomputing.com/, dans la section dédiée. La liste réelle est sans doute beaucoup plus longue.
10/03/2021, 10h37
danielhagnoul

Julia est encore jeune, laissez-lui du temps !
Python n'est très populaire dans l'enseignement que depuis quelques années seulement alors que sa première version est parue le 1/02/1991 !

Je pense que dans le futur, Julia ne remplacera jamais Python pour l'enseignement de la programmation, mais que les diplômés le rencontreront à leur travail.

Julia est très utilisé dans le domaine universitaire, son lieu de naissance, mais son utilisation se répand au-dehors et il rencontre beaucoup de succès.

Dans "What companies use the Julia programming language?"

Citation:

"Apple, Amazon, Facebook, BlackRock, Ford, Oracle, Comcast, Massachusetts General Hospital, Farmers Insurance, Los Alamos National Laboratory et le National Renewable Energy Laboratory exigent ce langage de programmation comme un incontournable dans les compétences d'un candidat méritant."

"La liste comprend des personnes dans des institutions telles que la NASA, CISCO, MIT et Berkeley."

Voir la page Julia Computing

Voir Featured Customers That Trust Julia Computing

Julia est un langage encore jeune, certains (dont je suis) pensent qu'il atteindra sa maturité avec la version 1.6 ou 1.7.

La 1.6 apporte plusieurs corrections et améliorations, la plus importante une très nette amélioration dans la gestion et la précompilation des paquets.

Le forum anglophone de Julia est dynamique : https://discourse.julialang.org/

Articles :
10/03/2021, 11h12
dourouc05

Dans la tech, Google aussi utilise Julia : https://www.linkedin.com/feed/update...02460264449%29
10/03/2021, 14h52
Invité

L'erreur serait de croire que Julia va remplacer Python tant la philosophie des deux langages est différentes.

Alors que Python mise sur les framework et sur les bibliothèques souvent écrites dans un langage compilé de bas niveau, l'ambition de Julia est au contraire d'offrir un environnement homogène et d'avoir le plus de composants possibles écrits en Julia.

Il y a eu un drama sur hackernews avant-hier à cause d'un billet de blog d'un data scientist qui ne croyait pas en Julia parce qu'on avait déjà Pandas, Matplotlib et Numba avec Python. C'est bien évidemment très réducteur comme façon de penser. Mais ça illustre bien le fossé entre les deux mondes.
10/03/2021, 15h10
Pyramidev
Personnellement, en dehors de l'écosystème, le seul gros manque que je vois en Julia par rapport au Python est qu'il ne supporte pas le typage statique optionnel. Mais, pour le reste, Julia semble répondre aux mêmes besoins que Python, avec de meilleures performances. Il n'y a plus qu'à attendre que l'écosystème se développe.

D'ailleurs, pour l'enseignement, syntaxiquement, Julia est plus convivial que Python, surtout si on l'utilise dans l'enseignement des mathématiques.
Exemple avec la REPL de Julia :
Code:

1 2 3 4 5 julia> f(x) = x^2 + 4x + cos(x) f (generic function with 1 method) julia> f(10) 139.16092847092355
Pour définir des fonctions en une ligne, la syntaxe colle bien à celle qu'on utilise en math. En outre, pour appeler des fonctions mathématiques basiques comme le cosinus, il n'y a pas besoin d'importer un module math.
10/03/2021, 22h00
defZero

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) ?

Je répondrais que des progiciels de gestion sont aujourd'hui codé en JS donc bon :aie: à partir de la plus de frein qui tiennent :mouarf:.

Personnellement ce qui me bloque plus, c'est la capacité à écrire sont code avec toute la palette Unicode.
Que l'on puisse l'utiliser dans des littéraux ou à l'intérieur de Buffer, OK, mais que l'on puisse coder en Cyrillique et que ce soit toujours du code valide, me pause plus de problèmes niveau refacto / compréhension.

Quels sont les freins pour votre adoption de Julia ?

Aucun, mais comme écrit dans les commentaire précédent, Julia n'est pas tellement un concurrent à qui que ce soit, mais plutôt une nouvelle possibilité à envisager pour ses projets.

D’ailleurs pour les commentaires précédents, "Python vs Julia" n'as pas de sens, puisqu'il ne font ni la même chose, ni ne fonctionnent de la même façon.

Bon courage à ceux qui voudrait lancer Julia sur iPad, iOS, AS/400, AIX et autres plateforme ou Python est présent.
De même accrochez vous pour pouvoir intégrer Julia comme Python dans Blender (de façon légère) par exemple ou encore pour lancer Julia comme MicroPython dans un µC.

Par contre, Julia pourrait tout à fait concurrencer Python pour certains usage où le "cold start" n'est pas dérangeant et où sa vitesse d’exécution et sa parallélisation native seraient des avantages, comme le web.
Mais encore faudrait-il qu'il y est une communauté / plateforme qui ce mette en place, dans ces domaines, pour y arriver.
13/08/2021, 13h36
Supernul
Citation:
Envoyé par Pyramidev

Personnellement, en dehors de l'écosystème, le seul gros manque que je vois en Julia par rapport au Python est qu'il ne supporte pas le typage statique optionnel. Mais, pour le reste, Julia semble répondre aux mêmes besoins que Python, avec de meilleures performances. Il n'y a plus qu'à attendre que l'écosystème se développe.

D'ailleurs, pour l'enseignement, syntaxiquement, Julia est plus convivial que Python, surtout si on l'utilise dans l'enseignement des mathématiques.
Exemple avec la REPL de Julia :

Code:

1 2 3 4 5 julia> f(x) = x^2 + 4x + cos(x) f (generic function with 1 method) julia> f(10) 139.16092847092355

Pour définir des fonctions en une ligne, la syntaxe colle bien à celle qu'on utilise en math. En outre, pour appeler des fonctions mathématiques basiques comme le cosinus, il n'y a pas besoin d'importer un module math.
En fait, on peut forcer le typage statique. Par exemple, en utilisant votre fonction :
Code:

1 2 3 4 5 julia> f(x::Int) = x^2 + 4x + cos(x) f (generic function with 1 method) julia> f(10) 139.16092847092355
f(10.0) renvoie une erreur
13/08/2021, 14h14
Pyramidev
Citation:
Envoyé par Supernul

En fait, on peut forcer le typage statique. Par exemple, en utilisant votre fonction :

Code:

1 2 3 4 5 julia> f(x::Int) = x^2 + 4x + cos(x) f (generic function with 1 method) julia> f(10) 139.16092847092355

f(10.0) renvoie une erreur
Ce n'est pas du typage statique. Le typage statique, c'est quand l'erreur de type est analysée par un outil qui lit le code sans l'exécuter.

Cela dit, depuis la dernière fois, j'ai appris l'existence de JET.jl qui est un outil d'analyse statique de code Julia qui arrive à détecter des erreurs de typage.

Par exemple, d'après la doc, pour le code :

fib(n) = n ≤ 2 ? n : fib(n-1) + fib(n-2) # fichier demo.jl, ligne 7
fib("1000") # fichier demo.jl, ligne 11

il écrit une erreur :

┌ @ demo.jl:11 fib("1000")
│┌ @ demo.jl:7 ≤(n::String, 2)
││┌ @ operators.jl:401 Base.<(x::String, y::Int64)
│││┌ @ operators.jl:352 Base.isless(x::String, y::Int64)
││││ no matching method found for call signature (Tuple{typeof(isless), String, Int64}): Base.isless(x::String, y::Int64)
│││└────────────────────
14/08/2021, 12h01
Supernul

Effectivement, j'ai répondu trop vite. Merci du rappel.