Hmmhmm, je pense comme toi que l'article est mauvais car on a l'impression qu'il essaye de trouver des points de comparaison entre les deux langages en s'appuyant que sur les particularités de Rust. Cela dénote alors une incompréhension sur certains exemples et de la mauvaise foi sur d'autres. On est bien d'accord.
Cependant, j'ai vu les commentaires qui se suivent et il y a une certaine incompréhension de l'objectif de Rust au final. Ce qu'il faut avant tout comprendre c'est pourquoi Mozilla s'entête a faire un langage. On pourrait dire que c'est la mode (Facebook avec Hack fait la même chose) mais je pense surtout que c'est un problème de mise à l'échelle par rapport aux problématiques d'aujourd'hui.
Il faut bien se rendre compte qu'aujourd'hui, le C++ n'offre pas les outils permettant d'invalider les programmes simples qui peuvent hypothétiquement être faux. Sur des programmes multi-threadés (donc avec scheduling partiel), il est bien loin de ce que propose les langages comme Scala, Erlang ou encore OCaml - sur ce point vous serez d'accord avec moi qu'il y a plus de chance d'avoir un segfault avec le C++ qu'avec ces derniers langages, notamment parce que le modèle mémoire est gérer par le langage.
Mais Mozilla veut maîtriser le modèle mémoire du langage (donc pas d'Erlang, pas d'OCaml, pas de Scala). Et c'est là l'objectif de Rust. C'est tout simplement pousser l'analyse statique le plus loin possible pour élaguer le plus d'erreurs possibles sur des programmes multi-threadés.
Ils ont donc rajouter deux notions dans le compilateur, à savoir l'appartenance d'une variable (ce qui est certe déjà présent en C++ avec shared/uniq/weak_ptr mais ce dernier n'est pas étudié statiquement) et l'idée d'une life-time pour les variables.
Et c'est sur ça qu'on dénote la qualité de fiabilité au langage Rust - car un programme ne passant pas ces analyses statiques ne compilera pas (comme un programme qui n'est pas bien typé en OCaml ne compilera pas). Cela permet donc de mettre en place des invariants et exécuter du code de manière safe. Et c'est sur ce point que Rust travaille par rapport au C++.
Alors, on peut ensuite critiquer cette position en disant que les tests unitaires sont suffisants par exemple pour valider le bon fonctionnement d'un programme. D'autant plus qu'une telle analyse va sûrement invalider des programmes qui sont justes (comme avec le système de type d'OCaml) et c'est bien la raison d'être de unsafe (comme Obj.magic en OCaml), à savoir bypasser l'analyse statique. Par exemple, il me semble impossible de faire un garbage collector en Rust pur et il faudrait sûrement passer par unsafe.
Au final, il faut bien comprendre que, oui, on code pas en C++ de cette manière, oui il y a des warnings dans certains exemples et oui, on a les outils nécessaires pour faire des programmes qui ont moins de chance de planter en C++ (mais qui n'assure rien avant un coup de GDB). Mais sur tout ces points, on vous empêchera pas de faire du mauvais code. On vous dire peut être qu'il faut pas faire comme ça. Rust vous empêchera de faire ce genre de code, il le compilera pas. Et cette nuance bien que minime, sur des projets de grandes ampleurs a son importance - c'est bien pour ça que Facebook a refait un PHP statiquement typé et un type-checker pour JavaScript.
[^] # Re: Comparaison ?
Posté par Dinosaure (site web personnel) . En réponse au journal Journal Bookmark #2. Évalué à 1.
Hmmhmm, je pense comme toi que l'article est mauvais car on a l'impression qu'il essaye de trouver des points de comparaison entre les deux langages en s'appuyant que sur les particularités de Rust. Cela dénote alors une incompréhension sur certains exemples et de la mauvaise foi sur d'autres. On est bien d'accord.
Cependant, j'ai vu les commentaires qui se suivent et il y a une certaine incompréhension de l'objectif de Rust au final. Ce qu'il faut avant tout comprendre c'est pourquoi Mozilla s'entête a faire un langage. On pourrait dire que c'est la mode (Facebook avec Hack fait la même chose) mais je pense surtout que c'est un problème de mise à l'échelle par rapport aux problématiques d'aujourd'hui.
Il faut bien se rendre compte qu'aujourd'hui, le C++ n'offre pas les outils permettant d'invalider les programmes simples qui peuvent hypothétiquement être faux. Sur des programmes multi-threadés (donc avec scheduling partiel), il est bien loin de ce que propose les langages comme Scala, Erlang ou encore OCaml - sur ce point vous serez d'accord avec moi qu'il y a plus de chance d'avoir un segfault avec le C++ qu'avec ces derniers langages, notamment parce que le modèle mémoire est gérer par le langage.
Mais Mozilla veut maîtriser le modèle mémoire du langage (donc pas d'Erlang, pas d'OCaml, pas de Scala). Et c'est là l'objectif de Rust. C'est tout simplement pousser l'analyse statique le plus loin possible pour élaguer le plus d'erreurs possibles sur des programmes multi-threadés.
Ils ont donc rajouter deux notions dans le compilateur, à savoir l'appartenance d'une variable (ce qui est certe déjà présent en C++ avec shared/uniq/weak_ptr mais ce dernier n'est pas étudié statiquement) et l'idée d'une life-time pour les variables.
Et c'est sur ça qu'on dénote la qualité de fiabilité au langage Rust - car un programme ne passant pas ces analyses statiques ne compilera pas (comme un programme qui n'est pas bien typé en OCaml ne compilera pas). Cela permet donc de mettre en place des invariants et exécuter du code de manière safe. Et c'est sur ce point que Rust travaille par rapport au C++.
Alors, on peut ensuite critiquer cette position en disant que les tests unitaires sont suffisants par exemple pour valider le bon fonctionnement d'un programme. D'autant plus qu'une telle analyse va sûrement invalider des programmes qui sont justes (comme avec le système de type d'OCaml) et c'est bien la raison d'être de
unsafe(commeObj.magicen OCaml), à savoir bypasser l'analyse statique. Par exemple, il me semble impossible de faire un garbage collector en Rust pur et il faudrait sûrement passer parunsafe.Au final, il faut bien comprendre que, oui, on code pas en C++ de cette manière, oui il y a des warnings dans certains exemples et oui, on a les outils nécessaires pour faire des programmes qui ont moins de chance de planter en C++ (mais qui n'assure rien avant un coup de GDB). Mais sur tout ces points, on vous empêchera pas de faire du mauvais code. On vous dire peut être qu'il faut pas faire comme ça. Rust vous empêchera de faire ce genre de code, il le compilera pas. Et cette nuance bien que minime, sur des projets de grandes ampleurs a son importance - c'est bien pour ça que Facebook a refait un PHP statiquement typé et un type-checker pour JavaScript.