Les avantages et inconvénients d'un langage reflètent en général le but initial pour lequel il a été créé et n'ont de sens qu'étant donné un contexte.
Concernant Rust, il me semble quand même assez marqué par le fait d'avoir été prévu pour écrire des navigateurs et remplacer du C++ fragile dans certaines parties sensibles de firefox. Partant de là, la complexité du système de types, du système de macros, ou la lenteur de la compilation ne sont pas des éléments nouveaux. Même le système d'ownership apporte une complexité qui n'est pas tout à fait étrangère au C++ avec le RAII etc.
Quand la comparaison se fait avec des langages aux caractéristiques très différentes (comme Go ou Java), c'est difficile de dire que tel ou tel truc devrait être comme dans Rust ou l'inverse, tellement un changement impacterait souvent le reste de façon non triviale. Je peux par exemple aimer le pattern matching en OCaml ou Rust tout en préférant que Go n'en ait pas. De même, je peux apprécier les types somme dans certains langages tout en les considérant une mauvaise idée pour Go (ça s'harmonise pas bien avec le concept de valeur par défaut pour les types, et il y a redondance avec l'utilisation des type-switch et des constantes).
Il n'y a pas de consensus scientifique (ni communautaire) qui dit qu'un langage généraliste, indépendamment de son domaine de prédilection, devrait avoir un système de types évolué, ou un système de macros, ou alors le contraire un système de types simple avec réflection. Il y a des approchent qui ne se complémentent pas simplement et orthogonalement, certains objectifs sont incompatibles avec certaines recherches.
Les rares trucs sur lesquels il y a plus ou moins consensus, c'est sur des implications immédiates pour lesquelles il manque un contexte et des stats d'impact pratique : macros + système de types complexe + abstractions zéro-coût = compilation lente ; existence d'assertions de types ou typage dynamique = possibilité d'erreur de typage au runtime ; exceptions = une parties des inconvénients du goto ; pas de types génériques = pas de bibliothèques génériques ; typage statique = manque d'expressivité ou système de typage complexe, etc...
[^] # Re: Pourquoi Rust ?
Posté par anaseto . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 3.
Les avantages et inconvénients d'un langage reflètent en général le but initial pour lequel il a été créé et n'ont de sens qu'étant donné un contexte.
Concernant Rust, il me semble quand même assez marqué par le fait d'avoir été prévu pour écrire des navigateurs et remplacer du C++ fragile dans certaines parties sensibles de firefox. Partant de là, la complexité du système de types, du système de macros, ou la lenteur de la compilation ne sont pas des éléments nouveaux. Même le système d'ownership apporte une complexité qui n'est pas tout à fait étrangère au C++ avec le RAII etc.
Quand la comparaison se fait avec des langages aux caractéristiques très différentes (comme Go ou Java), c'est difficile de dire que tel ou tel truc devrait être comme dans Rust ou l'inverse, tellement un changement impacterait souvent le reste de façon non triviale. Je peux par exemple aimer le pattern matching en OCaml ou Rust tout en préférant que Go n'en ait pas. De même, je peux apprécier les types somme dans certains langages tout en les considérant une mauvaise idée pour Go (ça s'harmonise pas bien avec le concept de valeur par défaut pour les types, et il y a redondance avec l'utilisation des type-switch et des constantes).
Il n'y a pas de consensus scientifique (ni communautaire) qui dit qu'un langage généraliste, indépendamment de son domaine de prédilection, devrait avoir un système de types évolué, ou un système de macros, ou alors le contraire un système de types simple avec réflection. Il y a des approchent qui ne se complémentent pas simplement et orthogonalement, certains objectifs sont incompatibles avec certaines recherches.
Les rares trucs sur lesquels il y a plus ou moins consensus, c'est sur des implications immédiates pour lesquelles il manque un contexte et des stats d'impact pratique : macros + système de types complexe + abstractions zéro-coût = compilation lente ; existence d'assertions de types ou typage dynamique = possibilité d'erreur de typage au runtime ; exceptions = une parties des inconvénients du goto ; pas de types génériques = pas de bibliothèques génériques ; typage statique = manque d'expressivité ou système de typage complexe, etc...