Rust, Go & Elixir sont des langages très différents, et leur approches du parallélisme est du coup différente :
Rust est un langage système généraliste sans runtime par défaut (ce qui est indispensable quand on veut faire un module noyau par exemple, moins si on veut faire une petite web-app—l'absence de GC pour des gros volumes de données peut faire la différence parfois). Il permet d'avoir les performances brutes de C/C++ et des garanties fortes sur le code, mais le prix à payer est en autres que le langage est clairement difficile à maîtriser. Pour le parallélisme, on travaille de base avec des threads mais il apporte la garantie qu'on ne pourra pas modifier un même objet depuis 2 threads sans protection (genre mutex), ce qui n'est pas le cas en Go.
Go se compile en natif mais vient avec un runtime pour le garbagecollector et l'ordonnanceur des routines. Le langage est très simple à apprendre et on code rapidement des choses qui marchent correctement, mais c'est le langage le moins expressif des 3 et il va y avoir plus de code boilerplate et moins de garanties sur l'exactitude du code qu'avec les 2 autres.
Elixir (je connais plus Erlang, je vais m'appuyer donc sur ce dernier, j'espère ne pas dire trop de bêtises) se base sur la VM Erlang, on a donc affaire à quelque chose de solide pour faire des services réseaux scalables et fiables, mais au détriment de performances brutes plus faibles (VM + typage dynamique).
Dans la mesure où tu regardes du côté de Go & Elixir, même si tu ne le précises pas, je suppose que tu envisages ces langages dans le cadre d'un service réseau. Le parallélisme de Rust est très bien si tu veux faire un moteur 3D par exemple, mais c'est sûr qu'il n'aura pas forcément la facilité d'utilisation des goroutines/micro-processus Erlang dans des cas plus spécifiques.
Si j'ai bien compris il existe en Rust plusieurs bibliothèques permettant d'utiliser async/wait (comme vu au dessus, vu les objectifs "système" du langage, imposer un runtime de base n'est pas souhaitable), mais on n'arrive pas à la facilité d'utilisation des routines (on a les garanties de Rust en compensation). J'ai aussi vu passer des systèmes d'acteurs façon Erlang pour Rust ; ça me semble une piste très intéressante, mais tout va dépendre de la maturité/pérennité de ces briques évidemment...
Pour répondre à ta question, bien que ne connaissant pas vraiment Zig, vu ses objectifs (système etc...), je suppose que sa situation doit être à comparer à celle de Rust.
[^] # Re: Et le parallélisme ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche De Zig et des zags. Évalué à 9.
Rust, Go & Elixir sont des langages très différents, et leur approches du parallélisme est du coup différente :
Dans la mesure où tu regardes du côté de Go & Elixir, même si tu ne le précises pas, je suppose que tu envisages ces langages dans le cadre d'un service réseau. Le parallélisme de Rust est très bien si tu veux faire un moteur 3D par exemple, mais c'est sûr qu'il n'aura pas forcément la facilité d'utilisation des goroutines/micro-processus Erlang dans des cas plus spécifiques.
Si j'ai bien compris il existe en Rust plusieurs bibliothèques permettant d'utiliser async/wait (comme vu au dessus, vu les objectifs "système" du langage, imposer un runtime de base n'est pas souhaitable), mais on n'arrive pas à la facilité d'utilisation des routines (on a les garanties de Rust en compensation). J'ai aussi vu passer des systèmes d'acteurs façon Erlang pour Rust ; ça me semble une piste très intéressante, mais tout va dépendre de la maturité/pérennité de ces briques évidemment...
Pour répondre à ta question, bien que ne connaissant pas vraiment Zig, vu ses objectifs (système etc...), je suppose que sa situation doit être à comparer à celle de Rust.