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.
# On s’en fiche que ça soit « écrit en Rust »
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+10/-2).
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é à 5 (+2/-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é à 6 (+5/-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é à 2 (+0/-0).
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.
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.