Dans le cas général, ça sera beaucoup plus intéressant pour les utilisateurs de communiquer sur les avantages fonctionnels que sur le langage utilisé pour coder l’outil.
Venant juste de finir de regarder My 2025 uv-based Python Project Layout for Production Apps par Hynek Schlawack, je dirais que sur le second cas, "extremely fast" et "in Rust" sont justement un des avantages (du non fonctionnel certes), avec une meilleure gestion des dépendances et de l'outillage d'empaquetage. Autant une app générique écrit en Rust ou autres, on peut se dire peu importe, autant un outil dédié à un langage dans un autre langage, ça interroge toujours un peu (est-ce le temps de bootstrapper le nouveau langage ? Une limitation actuelle du langage le temps de définir la norme ? Etc.).
Après sur un outil de renommage de fichiers, je suis plus intéressé par les fonctionnalités effectivement, à savoir s'il sera dispo en standard ou pas dans ma distribution/conteneur, s'il fait des blagues comme 'rename' qui est différent suivant les distributions, etc.
Ici, le projet a été créé notamment pour découvrir et apprendre la libraire "iocraft", une librairie pour faire des TUI en Rust, avec une expérience similaire à React+Flexbox, qui selon moi est une bien meilleure expérience que ratatui.
Oui, le seul argument c'est "écrit en Rust", car cela s'adresse principalement aux gens qui sont intéressé par le développement d'application en Rust.
Si c’est un projet dont le but est de tester et démontrer des intégrations de bibliothèques ou des architectures spécifiques à un langage – et donc qui s’adresse à des développeurs –, c’est un projet intéressant (et c’est dit sans ironie).
Mais dans ce cas, autant que ça soit clair dans le readme du projet et dans le message de partage. Ici, rien ne l’indique. L’utilisateur standard arrive devant ce truc, tout ce qu’il voit c’est un projet sans grand intérêt fonctionnel et promu sur un critère technique. Et donc c’est nul.
J'ai très honnêtement passé plus de temps à trouver comment faire une capture d'une session de terminal (asciinema est génial au passage !) qu'à écrire le README pour un projet de moins de 500 lignes bourré de copier/coller :p
c’est un projet sans grand intérêt
Oui, tout à fait. Et je pense que ça vaut quand même le coup d'être partagé. Sur lobste.rs par exemple, cela m'a permis de découvrir les outils que d'autres utilisent pour répondre à ce besoin.
Si c'est écrit en Rust, je me dis qu'il y a des chances que
l'outil soit un binaire standalone et c'est ce que je préfère installer.
l'outil soit rapide et ne prenne pas trop de mémoire pour rien
je puisse le builder si il n'y a pas de release binaire
que je puisse contribuer … quand je saurai faire du Rust pour de vrai
Si c'est écrit en Go, Elixir ou en Python, ça me va aussi, je saurai me débrouiller.
Si c'est écrit en C/C++, je tique un peu plus car je sais que le build sera une galère.
Si c'est écrit en JS/TS, je n'y touche même pas.
Les goûts et le couleurs, ça se discute bien sûr mais là ça annonce la couleur.
l'outil soit un binaire standalone et c'est ce que je préfère installer.
En quoi c'est un avantage ?
Du coup, qu'elle est la taille du binaire "écrit en Rust". Parce que faire des binaires compilés statiquement, tu peux le faire en C.
Un des plus (ou le plus) gros problèmes de performance est lié à la taille des binaires (pour cela qu'O2 donne bien souvent de meilleurs résultats qu'O3).
Pour ceux qui ont la toolchain Rust d'installé c'est facile à compiler et installer avec l'outil cargo. Ça ne sera pas un avantage pour tout le monde, mais pour moi ça l'est.
Du coup, qu'elle est la taille du binaire "écrit en Rust". Parce que faire des binaires compilés statiquement, tu peux le faire en C.
Si la personne ne fournit pas le binaire et que tu veux compiler toi-même, généralement en C la gestion des dépendances est plus compliqué.
Un des plus (ou le plus) gros problèmes de performance est lié à la taille des binaires (pour cela qu'O2 donne bien souvent de meilleurs résultats qu'O3).
Je crois que le point sur les performances c'était entre programme écrit en langage interprété et ceux écrits en langage compilé, donc la question de la taille des binaires n'a pas de sens dans le propos de @steph1978.
Compris, j'aime bien l'idée de Rust, mais je souhaiterai vraiment avoir un linker et un partage au niveau du binaire. Peut-être est-ce possible…
L'intérêt d'avoir des binaires :
Moins d'espace disque ;
Réutilisation, en mémoire, des pages RO (la section code des librairies) ;
Load (beaucoup) plus rapide du code ré-allocatable ;
Sans parler des m.a.j. fonctionnelles ou de sécurité.
Si il y a plusieurs processus qui utilisent un même programme Rust, la mémoire est-elle totalement privée et donc, consommée 2 fois ?
Comment le binding est fait ? avec une table de symbole, externe au section code, ou la "localisation" du symbole doit être effectuée pour chaque appel (dans la section code)?
Je comprends ce principe pour une page web, et dans le noyau, mais pour de grosses applications utilisateurs, moins.
Oui, même si ce n'est pas très mis en avant, il y a aussi moyen en Rust de faire des librairies partagées dynamique ou statique.
Rust utilise l'ABI C pour ça (et pour l’interaction avec d'autres langages)
Plus d'info dans la doc : Linkage
Si il y a plusieurs processus qui utilisent un même programme Rust, la mémoire est-elle totalement privée et donc, consommée 2 fois ?
La gestion des processus, ça se joue au niveau du système d'exploitation, pas du langage.
Je ne suis pas expert, mais dirais que le code est chargé une seule fois en mémoire, mais que chaque processus à sa propre mémoire pour le fonctionnement. Et bien sûr, ils peuvent aussi avoir de la mémoire partagée.
On peut construire des bibliothèques partagées en Rust. En particulier pour les utiliser dans d'autres langages compatibles avec l'ABI C. Il y en a pléthore pour Python d'ailleurs car c'est l'approche naturelle quand on veut accélérer des parties calculatoires dans ce langage interprété.
avoir un linker et un partage au niveau du binaire
* Moins d'espace disque ;
* Réutilisation, en mémoire, des pages RO (la section code des librairies) ;
* Load (beaucoup) plus rapide du code ré-allocatable ;
Sans parler des m.a.j. fonctionnelles ou de sécurité.
Cependant, je suis moins convaincu par ces arguments pour plusieurs raisons :
Nos PC ont maintenant des GB de RAM, plus des MB ; la réutilisation de quelques pages de mémoire devient moins intéressants
Les binaires Rust font du load dynamiques des bibliothèques des plus communes : libc, libm.
Plus important, l'approche de Rust est de faire une compilation des dépendances à partir des sources afin, grâce à une analyse statique, de n'embarquer que les fonctions appelées et donc de n'avoir dans le binaire que les instructions réellement utiles à l'application.
Cela a pour effet - outre le fait d'augmenter le temps de compilation :( - de minimiser la taille du binaire à charger, de garantir la sécurité mémoire, mais aussi de réduire la surface d'attaque.
De toute façon, le développeur a toute latitude pour utiliser des bibliothèques chargées dynamiquement, au travers des FFI.
Alors oui, et non. Certes il y a moins de code attaquable dans le binaire, mais il est compilé statiquement. Donc si une dépendance obtient un correctif de sécurité, il faut le recompiler pour ne pas avoir un binaire qui traine avec une dépendance trouée et/ou obsolète.
# On s’en fiche que ça soit « écrit en Rust »
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+14/-3).
L’utilisateur s’en fiche que son outil soit « écrit en Rust ». Pourtant ici c’est le premier – et le seul ! – argument de promotion de l’outil.
C’est pas un cas isolé, en fait j’en ai déjà vu deux aujourd’hui et il n’est que 10h12, le second étant
uv, An extremely fast Python package and project manager, written in Rust (eux au moins annoncent déjà d’autres avantages).Dans le cas général, ça sera beaucoup plus intéressant pour les utilisateurs de communiquer sur les avantages fonctionnels que sur le langage utilisé pour coder l’outil.
La connaissance libre : https://zestedesavoir.com
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 04 avril 2025 à 11:12.
Venant juste de finir de regarder My 2025 uv-based Python Project Layout for Production Apps par Hynek Schlawack, je dirais que sur le second cas, "extremely fast" et "in Rust" sont justement un des avantages (du non fonctionnel certes), avec une meilleure gestion des dépendances et de l'outillage d'empaquetage. Autant une app générique écrit en Rust ou autres, on peut se dire peu importe, autant un outil dédié à un langage dans un autre langage, ça interroge toujours un peu (est-ce le temps de bootstrapper le nouveau langage ? Une limitation actuelle du langage le temps de définir la norme ? Etc.).
Après sur un outil de renommage de fichiers, je suis plus intéressé par les fonctionnalités effectivement, à savoir s'il sera dispo en standard ou pas dans ma distribution/conteneur, s'il fait des blagues comme 'rename' qui est différent suivant les distributions, etc.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par David Delassus (site web personnel) . Évalué à 5 (+4/-1).
Ici, le projet a été créé notamment pour découvrir et apprendre la libraire "iocraft", une librairie pour faire des TUI en Rust, avec une expérience similaire à React+Flexbox, qui selon moi est une bien meilleure expérience que ratatui.
Oui, le seul argument c'est "écrit en Rust", car cela s'adresse principalement aux gens qui sont intéressé par le développement d'application en Rust.
Fonctionnellement parlant, le logiciel n'est même pas si intéressant que ça. Il ne gère qu'un cas d'usage très limité. Il suffit de voir ce commentaire sur lobste.rs qui est bien plus intéressant que le tiens : https://lobste.rs/s/zxpqz0/regname_mass_renamer_tui_written_rust#c_igvgna
Ici on aime bien critiquer la forme et pas le fond :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8 (+7/-1).
Si c’est un projet dont le but est de tester et démontrer des intégrations de bibliothèques ou des architectures spécifiques à un langage – et donc qui s’adresse à des développeurs –, c’est un projet intéressant (et c’est dit sans ironie).
Mais dans ce cas, autant que ça soit clair dans le readme du projet et dans le message de partage. Ici, rien ne l’indique. L’utilisateur standard arrive devant ce truc, tout ce qu’il voit c’est un projet sans grand intérêt fonctionnel et promu sur un critère technique. Et donc c’est nul.
La connaissance libre : https://zestedesavoir.com
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par David Delassus (site web personnel) . Évalué à 4 (+3/-1).
J'ai très honnêtement passé plus de temps à trouver comment faire une capture d'une session de terminal (asciinema est génial au passage !) qu'à écrire le README pour un projet de moins de 500 lignes bourré de copier/coller :p
Oui, tout à fait. Et je pense que ça vaut quand même le coup d'être partagé. Sur lobste.rs par exemple, cela m'a permis de découvrir les outils que d'autres utilisent pour répondre à ce besoin.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . Évalué à 4 (+5/-3).
Perso je m'en fous pas.
Si c'est écrit en Rust, je me dis qu'il y a des chances que
Si c'est écrit en Go, Elixir ou en Python, ça me va aussi, je saurai me débrouiller.
Si c'est écrit en C/C++, je tique un peu plus car je sais que le build sera une galère.
Si c'est écrit en JS/TS, je n'y touche même pas.
Les goûts et le couleurs, ça se discute bien sûr mais là ça annonce la couleur.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
En quoi c'est un avantage ?
Du coup, qu'elle est la taille du binaire "écrit en Rust". Parce que faire des binaires compilés statiquement, tu peux le faire en C.
Un des plus (ou le plus) gros problèmes de performance est lié à la taille des binaires (pour cela qu'O2 donne bien souvent de meilleurs résultats qu'O3).
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par GwenLg . Évalué à 1 (+0/-0).
Pour ceux qui ont la toolchain Rust d'installé c'est facile à compiler et installer avec l'outil
cargo. Ça ne sera pas un avantage pour tout le monde, mais pour moi ça l'est.Si la personne ne fournit pas le binaire et que tu veux compiler toi-même, généralement en C la gestion des dépendances est plus compliqué.
Je crois que le point sur les performances c'était entre programme écrit en langage interprété et ceux écrits en langage compilé, donc la question de la taille des binaires n'a pas de sens dans le propos de @steph1978.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
Compris, j'aime bien l'idée de Rust, mais je souhaiterai vraiment avoir un linker et un partage au niveau du binaire. Peut-être est-ce possible…
L'intérêt d'avoir des binaires :
Sans parler des m.a.j. fonctionnelles ou de sécurité.
Si il y a plusieurs processus qui utilisent un même programme Rust, la mémoire est-elle totalement privée et donc, consommée 2 fois ?
Comment le binding est fait ? avec une table de symbole, externe au section code, ou la "localisation" du symbole doit être effectuée pour chaque appel (dans la section code)?
Je comprends ce principe pour une page web, et dans le noyau, mais pour de grosses applications utilisateurs, moins.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par GwenLg . Évalué à 1 (+0/-0).
Oui, même si ce n'est pas très mis en avant, il y a aussi moyen en Rust de faire des librairies partagées dynamique ou statique.
Rust utilise l'ABI C pour ça (et pour l’interaction avec d'autres langages)
Plus d'info dans la doc : Linkage
La gestion des processus, ça se joue au niveau du système d'exploitation, pas du langage.
Je ne suis pas expert, mais dirais que le code est chargé une seule fois en mémoire, mais que chaque processus à sa propre mémoire pour le fonctionnement. Et bien sûr, ils peuvent aussi avoir de la mémoire partagée.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . Évalué à 2 (+0/-0).
On peut construire des bibliothèques partagées en Rust. En particulier pour les utiliser dans d'autres langages compatibles avec l'ABI C. Il y en a pléthore pour Python d'ailleurs car c'est l'approche naturelle quand on veut accélérer des parties calculatoires dans ce langage interprété.
Cependant, je suis moins convaincu par ces arguments pour plusieurs raisons :
Nos PC ont maintenant des GB de RAM, plus des MB ; la réutilisation de quelques pages de mémoire devient moins intéressants
Les binaires Rust font du load dynamiques des bibliothèques des plus communes : libc, libm.
Plus important, l'approche de Rust est de faire une compilation des dépendances à partir des sources afin, grâce à une analyse statique, de n'embarquer que les fonctions appelées et donc de n'avoir dans le binaire que les instructions réellement utiles à l'application.
Cela a pour effet - outre le fait d'augmenter le temps de compilation :( - de minimiser la taille du binaire à charger, de garantir la sécurité mémoire, mais aussi de réduire la surface d'attaque.
De toute façon, le développeur a toute latitude pour utiliser des bibliothèques chargées dynamiquement, au travers des FFI.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par David Delassus (site web personnel) . Évalué à 4 (+3/-1).
Alors oui, et non. Certes il y a moins de code attaquable dans le binaire, mais il est compilé statiquement. Donc si une dépendance obtient un correctif de sécurité, il faut le recompiler pour ne pas avoir un binaire qui traine avec une dépendance trouée et/ou obsolète.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . Évalué à 2 (+0/-0).
Pour le cas qui nous concerne ici : 3.0MB.
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.