J'ai beaucoup aimé cet article, je trouve qu'il présente bien les fonctionnalité de ce langage qui semble encore plus intéressant à chaque version. Maintenant qu'il commence à se stabiliser, je pense que je vais finir par m'y mettre.
La gestion de la mémoire semble compliqué au premier abord mais j'aimerais ajouter pour ceux qui pense que c'est une hérésie que c'est aussi la voie vers laquelle le C++ s'oriente avec C++11 et C++14. Pour paraphraser Herb Sutter: "dans le futur, aucun programmeur C++ ne devrait utiliser le type pointeur, mais uniquement utiliser unique_ptr, shared_ptr, weak_ptr, ..." (http://herbsutter.com/elements-of-modern-c-style/). Certes le C++ est un langage très (trop ?) compliqué mais pour moi ceci prouve que la thématique de la mémoire est loin d'être réglée. On peut invoquer OCaml ou Java comme "success-story" pour le ramasse miette mais la réalité montre que que ce n'est pas si simple, même si cela marche très bien dans beaucoup de cas. D'où l'intérêt d'avoir une gestion intermédiaire, qui optimise statiquement le plus de cas possible. D'ailleurs, une partie de la recherche actuelle dans les langages de programmation porte sur une gestion encore plus fine des pointeurs (http://protz.github.io/mezzo/). D'ailleurs il me semble que la gestion de la mémoire par Rust n'est pas si éloignée de la logique linéaire, comme cela a été noté plus haut.
J'aimerais aussi ajouter un point sur la partie "objet": j'ai lu certains commentaires de gens qui trouve le mélange objet/fonctionnel un peu étrange. Je trouve au contraire que le compromis atteint est très bon: les fameuses 15 dernières années de recherche en langages de programmation ont montré que concevoir un langage de programmation objet correct est extrêmement difficile, d'ailleurs la plupart des langage objets n'ont pas une sémantique claire. Il a fallut atteindre 2012 pour que quelqu'un démontre que le C++ avait une sémantique correcte (http://herbsutter.com/elements-of-modern-c-style/) et encore, cette étude a montré que la spécification est vague, voir contradictoire, et dans de nombreux cas complètement contre-intuitive, et elle a même menée à des corrections de la spécification. Ceci semble indiquer que l'approche "C++" ou "Java" des objets n'est pas la bonne: elle semble sympathique mais engendre énormément de problèmes, principalement par son manque de sécurité. L'approche des "traits" me semble plus intéressante: elle conserve la partie intéressante des objets, à savoir l'interface, elle donne la possibilité à un objet d'avoir plusieurs interfaces, et surtout elle dissocie complètement l'objet et l'implémentation de son interface. D'où une question intéressante: est-ce que Rust possède une sémantique correcte ?
Enfin il est vraiment très appréciable de retrouver de nombreux aspects des langages fonctionnels, comme les lambda fonctions, les types sommes, car ce sont des notions très puissantes que l'on comprend bien. La gestion des erreurs par les "conditions" est aussi intéressante, lorsque utilisée à bon escient.
# De la complexité de la gestion de la mémoire et d'autres
Posté par pamaury . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 10.
J'ai beaucoup aimé cet article, je trouve qu'il présente bien les fonctionnalité de ce langage qui semble encore plus intéressant à chaque version. Maintenant qu'il commence à se stabiliser, je pense que je vais finir par m'y mettre.
La gestion de la mémoire semble compliqué au premier abord mais j'aimerais ajouter pour ceux qui pense que c'est une hérésie que c'est aussi la voie vers laquelle le C++ s'oriente avec C++11 et C++14. Pour paraphraser Herb Sutter: "dans le futur, aucun programmeur C++ ne devrait utiliser le type pointeur, mais uniquement utiliser unique_ptr, shared_ptr, weak_ptr, ..." (http://herbsutter.com/elements-of-modern-c-style/). Certes le C++ est un langage très (trop ?) compliqué mais pour moi ceci prouve que la thématique de la mémoire est loin d'être réglée. On peut invoquer OCaml ou Java comme "success-story" pour le ramasse miette mais la réalité montre que que ce n'est pas si simple, même si cela marche très bien dans beaucoup de cas. D'où l'intérêt d'avoir une gestion intermédiaire, qui optimise statiquement le plus de cas possible. D'ailleurs, une partie de la recherche actuelle dans les langages de programmation porte sur une gestion encore plus fine des pointeurs (http://protz.github.io/mezzo/). D'ailleurs il me semble que la gestion de la mémoire par Rust n'est pas si éloignée de la logique linéaire, comme cela a été noté plus haut.
J'aimerais aussi ajouter un point sur la partie "objet": j'ai lu certains commentaires de gens qui trouve le mélange objet/fonctionnel un peu étrange. Je trouve au contraire que le compromis atteint est très bon: les fameuses 15 dernières années de recherche en langages de programmation ont montré que concevoir un langage de programmation objet correct est extrêmement difficile, d'ailleurs la plupart des langage objets n'ont pas une sémantique claire. Il a fallut atteindre 2012 pour que quelqu'un démontre que le C++ avait une sémantique correcte (http://herbsutter.com/elements-of-modern-c-style/) et encore, cette étude a montré que la spécification est vague, voir contradictoire, et dans de nombreux cas complètement contre-intuitive, et elle a même menée à des corrections de la spécification. Ceci semble indiquer que l'approche "C++" ou "Java" des objets n'est pas la bonne: elle semble sympathique mais engendre énormément de problèmes, principalement par son manque de sécurité. L'approche des "traits" me semble plus intéressante: elle conserve la partie intéressante des objets, à savoir l'interface, elle donne la possibilité à un objet d'avoir plusieurs interfaces, et surtout elle dissocie complètement l'objet et l'implémentation de son interface. D'où une question intéressante: est-ce que Rust possède une sémantique correcte ?
Enfin il est vraiment très appréciable de retrouver de nombreux aspects des langages fonctionnels, comme les lambda fonctions, les types sommes, car ce sont des notions très puissantes que l'on comprend bien. La gestion des erreurs par les "conditions" est aussi intéressante, lorsque utilisée à bon escient.