L'article parle de l'argument comme quoi Rust serait plus expressif et permet de faire des choses impossibles ou très compliquées en C++.
Il explore donc la conversion de code Rust en C++ et montre que le code obtenu est en général assez proche du point de vue de sa structure algorithmique, de sa gestion du cycle de vie des objets, etc.
Sa conclusion est qu'il n'y a pas de problème d'expressivité en C++: il permet d'écrire tout ce qu'on peut écrire en Rust, avec les mêmes résultats. L'avantage de Rust viendrait plutôt de la réjection des constructions invalides.
Je crois qu'il y a là un gros problème avec la description de l'expressivité. Cette vision se concentre uniquement sur le code généré et exécuté. Or, l'expressivité de Rust, elle est plutôt dans les possibilités d'expliciter toutes sortes de choses qui justement ne sont pas utile une fois le code compilé. Mais qui sont par contre essentielles pour que le compilateur puisse bien faire son travail de vérification, et aussi pour que les développeurs du projet aient cette information.
Cela va même plus loin puisque, si j'ai bien compris, l'auteur compare des lignes de code C++ sans les tests, et des lignes de code Rust avec les tests, car en Rust, les tests sont dans le même fichier que l'implémentation. Forcément, cela permet de conclure que le code C++ est plus petit…
Finalement la chose à retenir est peut-être là: la valeur de Rust n'est pas d'écrire du meilleur code dans l'absolu. Elle est surtout de communiquer clairement la construction de votre code, non seulement avec le compilateur qui pourra peut-être mieux l'optimiser (je m'attendais à voir quelques mesures de performances ou de taille d'exécutables obtenues, mais non, rien du tout); mais surtout avec vos collègues ou le vous du futur qui va devoir relire, modifier et maintenir ce code. Dommage de passer à côté de ça, non?
Il me semble qu'il est assez clair sur l'expressivité, même si effectivement on peut inclure dans ce terme ce qui s'adresse au compilateur. Je pense que le projet était surtout de montrer que ce qui est fonctionnellement faisable en Rust l'est aussi en C++ pour un coût équivalent. Il ne cache pas cependant que les garanties offertes par le compilateur Rust sont toutes perdues en C++.
Le coup du compte des lignes de code avec et sans tests m'a surpris aussi ; la comparaison ne tient pas la route. J'aurais aussi voulu avoir des benchmarks. Après, tout cela a été vibe-codé et sans doute vibe-rédigé donc je ne m'attends pas à une rigueur exemplaire :)
Oui c'est un peu plus clair en lisant l'article référencé sur la définition de l'expressivité.
Given two universal programming language that only differ by a set of programming constructs {c1, … cn}, the relation holds if the additional constructs do not make the larger language more expressive than the smaller one. Here “more expressive” means that
the translation of a program with occurrences of one of the constructs ci to the smaller language requires a global reorganization of the entire program.
C'est lié à la notion de "sucre syntaxique": des constructions supplémentaires qui sont trivialement traduites en constructions plus simples, et dont la suppression en passant d'un langage à l'autre n'aboutit pas à une réorganisation de tout le programme.
Avec cette définition, intuitivement, le C++ est plus expressif. Il a des pointeurs avec lesquels on peut faire de l'arithmétique , des accès hors des bornes, des accès à de la mémoire déjà libérée, par exemple.
Donc avec cette définition, l'avantage du Rust serait qu'il est moins expressif: il rend impossible d'écrire certaines choses, ou au moins il faut considérablement refactoriser le code pour y parvenir. Mais avec cette définition, l'assembleur est probablement le langage le plus expressif: celui qui permet de tout faire. Pour moi ça pointe vers le fait que ce n'est pas vraiment la bonne notion ici.
Alors, les gens qui parlent de l'expressivité du Rust, utilisent-ils le mauvais terme, ou bien ont-ils une autre définition de l'expressivité d'un langage?
Mais avec cette définition, l'assembleur est probablement le langage le plus expressif: celui qui permet de tout faire. Pour moi ça pointe vers le fait que ce n'est pas vraiment la bonne notion ici.
Ben plutôt pas. Prend une feature présente en C++ et pas en asm, les template par exemple, les traduire en asm nécessite une transformation complexe, la compilation carrément, avec un programme qui n'a rien à voir et qui a perdu la généricité. Dans l'autre sens si tu comptes qu'on peut utiliser de l'asm (c'est tricher mais …) dans un programme C++ … C++ est strictement plus expressif que l'asm.
Dans un autre sens simuler une machine ASM en C++ permet de réutiliser le programme asm sans trop trop d'efforts, et là on a pas spécifié la relation entre le langage et l'implémentation ou la machine.
To avoid restrictive assumptions about the set of programming languages, the
Gefinition only requires that the semantics observe the termination behavior of
programs.
Il y a une nécessité de terminaison, et on peut quand même donc supposer que la correction des programmes est un critère. Pour un accès hors borne, par exemple, on a un comportement non défini y compris en asm, donc on ne peut plus supposer que le programme termine … pour moi donc si le programme en Rust ne compile pas il n'y a pas perte d'expressivité par rapport à l'assembleur.
# Y'a un truc qui me chiffonne
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+10/-0).
L'article parle de l'argument comme quoi Rust serait plus expressif et permet de faire des choses impossibles ou très compliquées en C++.
Il explore donc la conversion de code Rust en C++ et montre que le code obtenu est en général assez proche du point de vue de sa structure algorithmique, de sa gestion du cycle de vie des objets, etc.
Sa conclusion est qu'il n'y a pas de problème d'expressivité en C++: il permet d'écrire tout ce qu'on peut écrire en Rust, avec les mêmes résultats. L'avantage de Rust viendrait plutôt de la réjection des constructions invalides.
Je crois qu'il y a là un gros problème avec la description de l'expressivité. Cette vision se concentre uniquement sur le code généré et exécuté. Or, l'expressivité de Rust, elle est plutôt dans les possibilités d'expliciter toutes sortes de choses qui justement ne sont pas utile une fois le code compilé. Mais qui sont par contre essentielles pour que le compilateur puisse bien faire son travail de vérification, et aussi pour que les développeurs du projet aient cette information.
Cela va même plus loin puisque, si j'ai bien compris, l'auteur compare des lignes de code C++ sans les tests, et des lignes de code Rust avec les tests, car en Rust, les tests sont dans le même fichier que l'implémentation. Forcément, cela permet de conclure que le code C++ est plus petit…
Finalement la chose à retenir est peut-être là: la valeur de Rust n'est pas d'écrire du meilleur code dans l'absolu. Elle est surtout de communiquer clairement la construction de votre code, non seulement avec le compilateur qui pourra peut-être mieux l'optimiser (je m'attendais à voir quelques mesures de performances ou de taille d'exécutables obtenues, mais non, rien du tout); mais surtout avec vos collègues ou le vous du futur qui va devoir relire, modifier et maintenir ce code. Dommage de passer à côté de ça, non?
[^] # Re: Y'a un truc qui me chiffonne
Posté par Julien Jorge (site web personnel) . Évalué à 4 (+2/-0).
Il me semble qu'il est assez clair sur l'expressivité, même si effectivement on peut inclure dans ce terme ce qui s'adresse au compilateur. Je pense que le projet était surtout de montrer que ce qui est fonctionnellement faisable en Rust l'est aussi en C++ pour un coût équivalent. Il ne cache pas cependant que les garanties offertes par le compilateur Rust sont toutes perdues en C++.
Le coup du compte des lignes de code avec et sans tests m'a surpris aussi ; la comparaison ne tient pas la route. J'aurais aussi voulu avoir des benchmarks. Après, tout cela a été vibe-codé et sans doute vibe-rédigé donc je ne m'attends pas à une rigueur exemplaire :)
[^] # Re: Y'a un truc qui me chiffonne
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Oui c'est un peu plus clair en lisant l'article référencé sur la définition de l'expressivité.
C'est lié à la notion de "sucre syntaxique": des constructions supplémentaires qui sont trivialement traduites en constructions plus simples, et dont la suppression en passant d'un langage à l'autre n'aboutit pas à une réorganisation de tout le programme.
Avec cette définition, intuitivement, le C++ est plus expressif. Il a des pointeurs avec lesquels on peut faire de l'arithmétique , des accès hors des bornes, des accès à de la mémoire déjà libérée, par exemple.
Donc avec cette définition, l'avantage du Rust serait qu'il est moins expressif: il rend impossible d'écrire certaines choses, ou au moins il faut considérablement refactoriser le code pour y parvenir. Mais avec cette définition, l'assembleur est probablement le langage le plus expressif: celui qui permet de tout faire. Pour moi ça pointe vers le fait que ce n'est pas vraiment la bonne notion ici.
Alors, les gens qui parlent de l'expressivité du Rust, utilisent-ils le mauvais terme, ou bien ont-ils une autre définition de l'expressivité d'un langage?
[^] # Re: Y'a un truc qui me chiffonne
Posté par thoasm . Évalué à 3 (+0/-0).
Ben plutôt pas. Prend une feature présente en C++ et pas en asm, les template par exemple, les traduire en asm nécessite une transformation complexe, la compilation carrément, avec un programme qui n'a rien à voir et qui a perdu la généricité. Dans l'autre sens si tu comptes qu'on peut utiliser de l'asm (c'est tricher mais …) dans un programme C++ … C++ est strictement plus expressif que l'asm.
Dans un autre sens simuler une machine ASM en C++ permet de réutiliser le programme asm sans trop trop d'efforts, et là on a pas spécifié la relation entre le langage et l'implémentation ou la machine.
Il y a une nécessité de terminaison, et on peut quand même donc supposer que la correction des programmes est un critère. Pour un accès hors borne, par exemple, on a un comportement non défini y compris en asm, donc on ne peut plus supposer que le programme termine … pour moi donc si le programme en Rust ne compile pas il n'y a pas perte d'expressivité par rapport à l'assembleur.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.