J’avais présenté, il y a quelque temps, trois utilitaires écrits en Rust pour remplacer grep, ls et find (à savoir ripgrep, exa et fd). Cette dépêche est l’occasion de présenter trois nouveaux utilitaires également écrits en Rust : delta, dust et watchexec.
delta
delta permet de mettre de la coloration syntaxique dans les diffs, et notamment ceux produits par Git. Il affiche avec un fond vert ce qui a été ajouté et avec un fond rouge ce qui a été supprimé, mais il met également en couleur les mots‑clés, opérateurs et structures propres à chaque langage de programmation. La coloration syntaxique provient de bat, et comme celui‑ci, il offre différents thèmes pour s’adapter aux goûts de chacun.
Dust
Dust s’inspire de l’utilitaire du. Il apporte du confort quand on veut trouver quels répertoires prennent de la place, grâce à quelques astuces :
- il fait automatiquement le tri, pas besoin de recourir à
sort; - il va également afficher les gros sous‑répertoires, pas seulement les répertoires de premier niveau ;
- son affichage graphique permet de mieux voir où l’espace est pris.
watchexec
watchexec permet de lancer des commandes dès qu’un fichier est modifié. C’est pratique pour relancer des tests, une compilation ou un serveur pour un développeur. Il s’appuie sur inotify sous GNU/Linux et ses équivalents pour macOS et Windows. Voici quelques exemples d’invocation :
-
watchexec makepermet de lancer la commandemakedès qu’un fichier est ajouté ou modifié dans le répertoire courant ; -
watchexec -w src -w spec rspecpermet de lancer des tests avecrspecdès qu’un fichier présent danssrcou dansspecest modifié ; -
watchexec -e py -r python server.pypermet de lancer ou relancer un serveur Python dès qu’un fichier avec l’extension.pyest modifié.
Aller plus loin
- Des alternatives à grep, ls et find (236 clics)
- Delta (266 clics)
- Dust (400 clics)
- Watchexec (179 clics)
# Portabilité ?
Posté par Francois Revol (site web personnel) . Évalué à 10.
La semaine dernière justement j'ai regardé les différents outils de surveillance des systèmes de fichier… la plupart sont absolument importables puisqu'ils se basent sur inotify uniquement. Pourtant plein d'OS ont des fonctions équivalentes, à commencer par BeOS y a 20 ans déjà.
Le seul que j'ai trouvé qui supporte à peu près tous les OS c'est fswatch. Enfin, il manque encore le support natif Haiku.
J'ai rien contre Rust, au contraire, la sécurité c'est important, mais la portabilité aussi c'est important…
Ah, visiblement watchexec supporte Win et OSX aussi, c'est déjà pas mal, mais il manque BSD… et Haiku, enfin pour l'instant.
Et visiblement comme fswatch il a un fallback générique pour les autres plateformes, ça c'est bien, ça permet de l'utiliser quand-même !
Du coup, avis aux BSDistes, Illumosiens… ;-)
[^] # Re: Portabilité ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Tu as testé watchexec sous Haiku ? A priori, il utilise le même mécanisme de polling comme fallback générique que fswatch.
Plus généralement, la portabilité pour ce genre d'outils est compliquée. Chaque OS a une API propre, avec un mode de fonctionnement légèrement différent du voisin, mais ses différences rendent vraiment compliqué d'avoir un outil générique.
Sous GNU/Linux, c'est inotify. On dit que l'on veut surveiller tout fichier ou répertoire et l'OS va nous envoyer des événements quand il y a des appels système qui concernent le fichier ou répertoire.
Sous macOS, c'est fsevents : par rapport à inotify, les événements pour un même fichier sont regroupés quand ils arrivent suffisamment proches. Par exemple, on peut recevoir un événement pour un fichier avec des flags « fichier créé », « fichier modifié » et « fichier déplacé » pour un fichier temporaire.
Sous Windows, ça s'appelle ReadDirectoryChangesW, et ça marche un peu comme inotify, mais en plus, il y a l'aspect recursif qui est pris en compte : quand on demande à surveiller un répertoire, on reçoit des événements quand un fichier dans un sous-sous-sous-répertoire est modifié (alors que pour inotify, il faut explicitement parcourir les sous-répertoires et mettre en place la surveillance de ces sous-répertoires). Par contre, dans les points négatifs, c'est plus compliqué de suivre les fichiers et répertoires déplacés.
Sous BSD, c'est kqueue. Je n'ai pas pratiqué, mais j'ai entendu dire que c'était plus efficace comme alternative pour epoll que comme alternative à inotify.
Pour Haiku et les autres, je ne saurais même pas dire ce qui est en place.
[^] # Re: Portabilité ?
Posté par Francois Revol (site web personnel) . Évalué à 9.
Oui je sais que c'est compliqué, c'est moi qui ai écrit le support filewatcher Haiku pour le client owncloud…
Malheureusement en effet aucune API de ce genre n'est standardisée, du coup on doit réinventer la roue (et parfois prétendre qu'on l'a trouvée en premier, comme avec le tickless :D). Sous BeOS le node_monitoring n'était pas récursif, donc sous Haiku on a fait une autre API en plus, plus flexible. De plus comme sous BeOS on peut avoir les notifications de modification des xattrs, mais bon, y a que nous qui les utilisons tfaçon les xattrs… Encore un truc pas standardisé, mais c'est une autre histoire, j'ai écrit un papier entier là dessus.
Pas encore testé non, le seul truc que j'ai voulu tester en Rust sous Haiku c'était pas encore ça, je sais plus s'il manquait des dépendances ou si j'avais juste plus de place disque… Bon, le portage est encore jeune. Mais à priori avec un fallback sur stat() comme fswatch ça devrait marcher.
[^] # Re: Portabilité ?
Posté par Narmer . Évalué à 2.
Je te conseille alors modd qui est écrit en go
https://github.com/cortesi/modd
Ce que j'aime est qu'il est configurable via un fichier de conf modd.conf, et tourne sous pas mal de différents OS (tous ceux supporté par Go en fait)
[^] # Re: Portabilité ?
Posté par Francois Revol (site web personnel) . Évalué à 2.
Oué, encore plus d'outils pour faire la même chose ;-)
Ah, c'est un démon avec un fichier de conf… pas tout à fait le même type d'usage.
Avec un truc comme fswatch, on lui passe le dossier courant en argument depuis un Makefile par exemple, et on lui demande d'appeler 'make', et on a une cible qui fait de l'intégration continue d'un simple 'make watch'.
# ncdu
Posté par Glandos . Évalué à 10.
Je rappelle l'existence de ncdu qui permet de faire le bilan de l'espace disque utilisé. Il est mentionné sur la page de Dust, mais il permet surtout de faire la différence entre l'espace utilisé par les fichiers, et l'espace alloué par le système de fichiers. Ce qui peut être assez différent…
# A propos de dust
Posté par Dring . Évalué à 3.
Cet outil m'intéresse bien ; à mi-chemin du coup entre tree et du. Et du coup j'ai des questions.
Quand on regarde la copie d'écran, où tu n'as tapé aucune option, on voit que le répertoire de départ apparaît en fin de liste. Je m'attendrais à l'inverse, d'autant que dans la doc, tu indiques qu'il y a une option "-r" qui met le répertoire racine en bas.
Pour la représentation des barres, quelle est la signification des nuances de gris ?
Et serait-il possible, pour les barres, de faire que visuellement elles soient séparées les unes des autres ? En utilisant par exemple un caractère comme le 25A0. Ca donne des trucs comme ça :
80% ■■■■■■■■■■■■■■■■
20% ■■■■
Après, utiliser des caractères étendus dans la console, ça peut donner des trucs zarbs, hein. En option peut-être ?
[^] # Re: A propos de dust
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Je ne suis pas l'auteur de ses outils, je ne fais que les présenter ici. L'option
-rpermet d'avoir le répertoire racine en haut. Je me serais également attendu à l'ordre inverse par défaut.Ça permet juste de voir quels sont les sous-répertoires qui sont dans un même répertoire.
Je ne vois pas d'option existante pour ça, mais si tu crées une issue sur github, l'auteur saura sûrement mieux te répondre que moi.
[^] # Re: A propos de dust
Posté par Dring . Évalué à 2.
Oups, désolé, j'ai cru que tu étais derrière la création de tout ça ! Evidemment, GitHub est sans doute le meilleur endroit pour lever ces points.
# rust
Posté par barmic 🦦 . Évalué à -3. Dernière modification le 12 mai 2020 à 07:34.
Il y a une forme de fétichisme pour rust ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Absolument pas. Je considère que Rust est un bon langage pour des choses de bas niveau où avoir un runtime important est un gros handicap. Je pense par exemple à l'écriture d'extensions pour des langages de script. Mais pour écrire un outil en ligne de commande, je préférerais d'autres langages comme Go ou Crystal. J'ai choisi les outils de cet dépêche parce que je les ai utilisés, pas spécialement parce qu'ils sont écrits en Rust.
D'ailleurs, dans la première dépêche, j'écrivais :
[^] # Re: rust
Posté par claudex . Évalué à 3.
Je ne comprends pas trop ce que tu veux dire. Si je lance https://github.com/bdrung/startup-time avec une version actuelle (un container sous Debian 10), j’obtiens:
On voit que Rust est légèrement plus rapide (vu que c’est mon portable et qu’il y a d’autres trucs qui tournent dessus, on ne peut pas dire que c’est vraiment plus rapide mais que c’est dans le même ordre de grandeur). Donc, je ne vois pas pourquoi Rust serait un plus mauvais choix que Go pour la CLI.
(tous les langages n’y sont pas, mais j’ai pris dès que j’avais les résultats pour Go et Rust)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 8.
OK, mes explications ne devaient pas être très claires. Je vais essayer de faire mieux.
Je considère qu'il y a deux groupes de langage pour faire un CLI : en gros, ceux qui peuvent faire un binaire rapide et facile à déployer, et ceux qui ont besoin de passer par un interpréteur qui va aller charger plusieurs modules, et va donc être à la fois plus compliqué à déployer et plus lent à charger. Et le premier groupe me paraît bien plus adapté pour des outils de type CLI.
Go et Rust font parti de ce premier groupe. Mais, à l'intérieur de ce groupe, je suis surpris par la place que prend Rust alors que, si c'était moi avait dû choisir, je serais plutôt parti sur un langage avec un garbage collector, comme Go ou OCaml. J'ai du mal à voir quel avantage Rust a par rapport à Go ou OCaml pour un outil de type CLI. Je vois bien l'intérêt de Rust dans d'autres contextes, mais pour un CLI, je suis vraiment perplexe.
Pourtant, j'observe que de plus en plus des outils récents de type CLI que j'utilise sont écrits en Rust, et j'imagine qu'il doit y avoir une raison derrière cela. Peut-être que c'est un effet de mode, peut-être qu'il y a une autre raison (un écosystème bien adapté ?), je ne saurais pas dire.
[^] # Re: rust
Posté par claudex . Évalué à 8.
La gestion de la mémoire pour un outil en CLI ne me semble pas particulièrement pénible en Rust (tu n'as pas vraiment le problème de plusieurs thread qui doivent accéder aux mêmes données). Donc je ne vois pas trop le problème.
Après, pourquoi Rust plutôt que Go. Je dirais (mais c'est vraiment une estimation au doigt mouillé) qu'on est plus du côté système et donc plus proche du point fort de Rust qui "déborde".
Pour OCaml, il semble un peu plus lent à l'exécution et culturellement moins orienté outils en CLI.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: rust
Posté par Dring . Évalué à 4.
D'ailleurs quelqu'un a une idée de pourquoi Free Pascal Compiler est beaucoup plus rapide que les autres ? J'ai cru à un effet de bord, mais c'est la même chose sur le site web du bench ; à tous les coups FPC est vainqueur et de loin.
C'est con, j'ai arrêté le Pascal y'a plus de 15 ans !
[^] # Re: rust
Posté par claudex . Évalué à 5.
Il est compilé en statique comparé au C.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: rust
Posté par Letho . Évalué à 6. Dernière modification le 12 mai 2020 à 12:19.
Je ne connais pas Go, mais pour ce qui est de Rust, il existe des outils très chouettes pour faire des outils en CLI – je pense notamment à la bibliothèque Clap1, à mon sens assez géniale.
Elle est utilisée notamment par Ripgrep, fd et watchexec.
Peut-être que cela joue ?
https://clap.rs/ ↩
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 4.
C'est possible. J'ai l'impression que cobra est un équivalent en Go de Clap qui n'a pas grand chose à lui envier, mais peut-être qu'il y a un écosystème et des ressources (articles, billets de blog) qui créent un contexte plus favorable en Rust.
[^] # Re: rust
Posté par cosmocat . Évalué à 2.
Elle supporte même les "verbes" que ne supporte pas la lip clap…
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 3.
A priori, clap prend ça aussi en charge, sous le nom de « subcommand ». Cf https://github.com/clap-rs/clap/blob/master/examples/20_subcommands.rs
[^] # Re: rust
Posté par cosmocat . Évalué à 2.
Ok. Merci pour la rectification. Ça me semblait étrange…
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 3.
Il y a un glissement dans ta réflexion entre, « j'ai trouvé des outils en rust » et « rust doit être mieux que les autres pour des outils cli ».
Si tu prendre d'autres exemples, par exemple httpie, vegeta et vtop. Ils sont écrit respectivement en python, go et js.
Je suis d'accord qu'en principe l'absence de runtime rend le démarrage plus rapide et que ce temps de démarrage peut être désagréable. Personnellement sur PC et laptop je ressent pas le temps de démarrage de python ou go, sur rpi je trouve que python commence à se faire sentir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Je n'ai pas été clair, je ne prétends pas que Rust soit mieux que les autres langages pour faire un outil CLI. En fait, si je devais choisir un langage pour faire un tel outil, je prendrais très probablement autre chose que Rust : Go, OCaml ou Crystal.
Je constate que les outils récents de type CLI que j'utilise sont quasiment tous écrits en Rust. Par récent, on va dire depuis 5 ans (ça correspond à peu près à la sortie de Rust 1.0). Les exemples que tu as donnés, httpie, vegeta et vtop, sont plus anciens et je ne les utilise pas (même si ça pourrait).
Je cherche une explication à cette observation. D'un côté, je comprends que Python, Ruby et Node.js soit mal adapté pour des outils de type CLI : ils ont un temps de chargement qui peut se ressentir en ligne de commande, notamment quand ils chargent pas mal de modules, et c'est plus compliqué à installer qu'un simple binaire à télécharger. Mais de l'autre, pourquoi Rust est privilégié par rapport à Go et d'autres langages comparables, ça m'échappe. Mon choix serait au contraire de préférer l'aspect pratique d'avoir un garbage collector, avoir des goroutines et channels, etc.
[^] # Re: rust
Posté par mothsART . Évalué à 9.
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
[^] # Re: rust
Posté par GuieA_7 (site web personnel) . Évalué à 6.
J'avoue que quand j'ai commencé à m'intéresser à Rust il y a pas mal d'années, le fait que Mozilla ait abandonné pas mal de technos me faisait assez peur. J'ai l'impression qu'aujourd'hui le projet est nettement plus porté pas la communauté, ce qui est une bonne chose.
[^] # Re: rust
Posté par mothsART . Évalué à -2.
https://www.youtube.com/watch?v=3w5cwBrvtf4
[^] # Re: rust
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Est-ce que les GC de Go/Crystal/OCaml/D… consomment forcément plus de mémoire que les pointeurs intelligents de Rust ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: rust
Posté par GuieA_7 (site web personnel) . Évalué à 4.
J'imagine que pour des programmes relativement petits comme ceux présentés, même si Rust va rendre l'écriture plus difficile, cela reste de bons terrains de jeux pour essayer d'écrire une implémentation (quasi) optimale (un peu comme on s'amuserait à coder la partie critique d'un code en ASM).
[^] # Re: rust
Posté par YetiBarBar . Évalué à 1.
Je crois qu'il faut un peu démystifié cette image de complexité du Rust.
Il y a un ticket initial de formation et un coût associé de développement un peu plus important lié à une rigueur du langage. Néanmoins, avec un peu d'habitude, tu apprends les bons paradigmes et, par la suite, tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…) ou à tenter de résoudre un obscur problème de concurrence que le caractère nazi t'empêchera de créer.
Je suis persuadé que tu te retrouver dans des situations tout aussi compliquées d'un point de vue dév. avec du C++. Dans le cas de Rust, le compilateur t'oblige à gérer proprement la mémoire et la concurrence. Dans le cas de C++, tu créés un bug mémoire ou de concurrence et tu cherches à le débugger…
Une petite comparaison pour la route:
- des dév. capable d'écrire du Python exécutable, ça se trouve à tous les coins de rue ou presque ;
- des dév. capable de me typer correctement du python, bien architecturé, qui passe les contrôles "qualité" et qui ne me fait pas un usage délibéré du duck-typing à tout va, c'est déjà plus compliqué, ça a un coût (en formation initiale et en dév.)
En tout état de cause, quand tu commences un dév, tu choisis ton langage en prenant en compte les facteurs suivants:
- est-ce que je connais, maîtrise et/ou désire apprendre le langage ;
- quel son les coûts acceptables en dév. / maintenance, etc… ;
- ai-je besoin d'une preuve de concept très rapide (Python?), la performance est-elle importante?
- vais-je mettre le prix pour avoir un truc robuste ou puis-je me contenter d'un script "à l'arrache" sur un coin de table ?
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Je n'ai pas compris ce que tu cherches à démystifier. Le fait que Rust soit complexe ?
Rust est un langage complexe (tout comme C++). C'est une complexité qui n'est pas là juste pour faire jolie, on se doute bien. Elle est là pour avoir un maximum de performances et une bonne stabilité.
Mais, il n'y a pas que les deux extrêmes : des bidouilleurs qui font du Python et des développeurs super consciencieux qui font du Rust. Il y a un large spectre entre les deux, et on retrouve notamment Go dans cet entre-deux. Rust est bien plus complexe que Go, et je ne vois rien dans tes propos pour expliquer pourquoi Rust ne serait pas si complexe que ça pour des outils de type CLI, ou en quoi cette complexité apporte des choses.
Tu évoques la gestion de la concurrence, mais Rust est loin d'être exemplaire dans ce domaine. Il n'interdit pas les deadlocks par exemple, contrairement à Pony et a un fonctionnement de plus bas niveau que d'autres langages, ce qui permet d'avoir des performances optimales mais a plutôt tendance à augmenter les risques de mal gérer ça. Les goroutines et channels sont plus faciles à apprivoiser que les futures et async/await. Et je ne parle même pas d'Erlang qui a, pour le coup, bien plus d'arguments à faire valoir sur ce domaine.
[^] # Re: rust
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Du coup tu n'a pas démystifié sa complexité ; tu as expliqué qu'elle se justifiait à moyen et long termes. Ce avec quoi je suis tout à fait d'accord (c'était l'essence même de mon commentaire précédant).
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 1.
Pour moi ce n'est pas le langage qui permette ça. C'est plutôt le workflow de déploiement (les tests que tu fais avant déploiement, la solidité de ton déploiement, la simplicité du rollback,…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par mothsART . Évalué à 3. Dernière modification le 13 mai 2020 à 23:50.
Ouais, enfin l'un n'empêche pas l'autre.
Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)
Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 3.
Je ne suis pas d'accord. Ça joue sur lors du développement. Si tu laisse passer un problème de typage en prod, le problème c'est pas le langage, c'est la qualité que tu livre. L'effort pour fournir la même qualité ne sera effectivement pas la même, mais hors cas pathologique (comme ce pourquoi a était fait rust pour remplacer c++), la différence ne sera pas si grande.
Tu parle de prod, parler de prod sans parler d'opérationnel, ça n'a pas de sens. Mais surtout si la prod est le problème du développeur alors son déploiement aussi. Sinon le fait que la prod tombe le vendredi à 18h ça n'est pas son problème.
Donc c'est bien une question de qualité de ce que tu livre. Mais les prods les plus solides vivent avec le fait qu'ils casseront leur prod. Parce qu'il est humainement impossible d'avoir un niveau de test suffisant pour garantir que tu ne casse jamais. Ça ne veut pas dire que tu ne va pas tout faire pour améliorer ta qualité, mais tu sais que reproduire la charge de ta prod est impossible par exemple. C'est pour que les canary release ou l'A/B testing existent.
Il faut les twelve factors et oui on est d'accord, mais dans tout ça il n'y a pas le typage de ton langage.
Je vais le dire autrement…
Tu veux fournir de la qualité. Tu as 2 stratégies possibles. Soit tu embauche les meilleurs développeurs possibles et ils choisissent le meilleur langage existant et code un excellent logiciel. Tout repose sur la qualité de chacun des développeurs. Soit tu cherche à avoir une qualité « systémique », c'est l'organisation de l'équipe qui produit de la qualité. C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité. Cette seconde stratégie est plus fiable car elle ne repose pas sur un recrutement trop complexe et est résiliente aux faiblesse ponctuelles qu'auront les développeurs.
Bref tout ça pour dire que les typages dynamiques et pire encore les typages faibles, je suis pas fan du tout, mais je ne les prendrais pas comme boucs émissaires en cas de problème en prod.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par mothsART . Évalué à 6. Dernière modification le 14 mai 2020 à 13:58.
En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 3.
C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,…) que tu es entrain de remettre en cause dans ce commentaire.
Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.
J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.
Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.
Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.
Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.
Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,… C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par mothsART . Évalué à 1. Dernière modification le 15 mai 2020 à 12:08.
Je n'ai jamais parlé d'une prod qui casse un vendredi.
Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.
Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
L'objectif est le même : prévenir plutôt que guérir.
Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
Le rollback c'est le joker au cas ou.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
T'as plein de cas ou tu ne peux pas te permettre ce luxe.
qlqs exemples loin d'être exhaustif :
- chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
- tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
- tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.
Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".
Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.
Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.
Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).
Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.
En client/serveur toujours, on parle de plus en plus d'isomorphisme.
Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.
Je ne fait pas que de l'antithèse.
[^] # Re: rust
Posté par claudex . Évalué à 4. Dernière modification le 15 mai 2020 à 13:40.
J'en ai vu aussi, ce n'est pas pour ça que je design mes systèmes pour ce cas-là. Parce qu'il y a déjà trop de problème quand on est dans cette situation.
Si tu as suffisamment de test, tu n'as pas peur de la prod.
Tu peux très bien designer ta migration pour être transparente. Soit tu duplique tes colonnes (soit via une procédure de la db, soit via l'application), et puis une fois que c'est migré, tu switch ton application. Soit tu as du schemaless et tu peux faire ton changement dans l'application. Le but c'est que ton application en version n-1 et n puisse accéder à la db, donc tu peux déployer tranquillement la nouvelle version et revenir en arrière de manière transparente.
Ça ne dépend pas de ton application. Normalement, tu as pu tester ton webservice avant et ton application peut gérer les deux versions et au moment où le webservice change, tu changes juste la config de ton application pour utiliser le nouveau. Après, pour les webservices bien fait, tu auras les deux versions en parallèle pendant un certain temps et tu pourras switcher sur le nouveau et revenir en arrière sur l'ancien pendant cette période.
Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.
Tu sais qu'il y a des systèmes qui font des rollback automatiquement ? En fonction des métriques de l'application (par exemple le nombre d'erreur 500, une baisse du nombre de requêtes…)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: rust
Posté par mothsART . Évalué à 2.
Entièrement dac. (c'est les tests, pas la capacité de rollback)
Je connais et applique tout ça.
Ca complexifie et l'expérience m'a montré que ça n'évite complètement les ratés.
Rien n'est parfait.
Sur des langage comme Rust, tu peux rendre l'ensemble de la base typé et amorcer des migrations ou tu peux garantir que les requètes avant et après migrations soient safe.
On en revient au point initial : un vrai truc typé de bout en bout t'évites d'envoyer de la merde en prod.
Normalement, un WS est versionné et tu peux passer de l'un à l'autre.
Le soucis c'est bien le "normalement" et le "bien fait". Si t'es consommateur, tu subis.
Dans l'absolu : oui. Mais la réalité fait que tu travailles sur du legacy ou tout n'est pas forcément possible aussi facilement.
Alors, oui. Bon, j'appel pas ça du rollback : t'as plusieurs versions de ton app/fonctionnalité et t'as des triggers en fonction de.
Ça peut être un vrai serpent de mer à plusieurs têtes si tu mets ça partout.
Comme souvent : faut savoir utiliser la bonne stack en fonction des besoins, ressources etc.
Ça peut être dur de trouver le bon curseur de déclenchement. faut que les métriques ne tombent pas, qu'elles soient temps réels etc.
Bref : du cas par cas.
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 2.
Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire. C'est juste le droit de travail. Être totalement hors des clous comme ça ce n'est même pas légal. C'est pas une question d'aimer le travail bien fait ou la passion pour ce qu'on fait. Accepter de travailler dans ces conditions et en plus considérer cela comme normal (pointer comme un quelqu'un qui ne veux pas s'engager et prendre pour soit le résultat de cet état de fait), ça dévalue ton travaille.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par mothsART . Évalué à 1.
Oula, tu fais des déductions rapides quand même là…
J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 2.
Quand je dis qu'une prod avec SLA ou du moins dont les gens veulent une disponibilité 24/7, ce qui me semble être sous-entendu par « la prod tombe le vendredi soir », demande un travail en équipe, des astreintes,… Tu me répond que je suis dans ma tour d'ivoire. Tu peux me dire que non c'est une prod qui n'est pas 24/7, mais du coup tu n'a pas à t'en occuper après ta journée de travail comme tu le dis dans le premier commentaire au quel je répond.
Vouloir une prod 24/7, c'est avoir quelqu'un qui régis aussi vite que possible aux problèmes. C'est ce dont tu parle dans ton premier commentaire : je ne l'invente pas. Ça s'appelle une astreinte et tu as légalement un quota d'heure d'astreinte limite donc tu dois travailler en équipe.
S'il s'agit d'une prod non 24/7, c'est en effet légal. Mais faut déclarer ses heures sup' ou que ce soit dans le cadre du forfait cadre et il faut surtout éviter de responsabiliser l'employé pour des défauts de la prod. L'importance de cette prod doit venir avec des moyens équivalents. Mais ça c'est juste une remarque.
La logique derrière ton allégorie de « la prod qui tombe à 18h » me semble être l'une des 2. Évidement je peux me tromper et évidement en ayant la facilité d'imaginer qu'une prod était généralement 24/7, j'ai suivi un raccourcis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par mothsART . Évalué à 1. Dernière modification le 15 mai 2020 à 20:49.
Oui, on ne parle de la même chose.
Quand je parlais de prod c'était très large.
ça peut être fournir un exe, un intranet : dans une de mes anciennes boite, on mettais à jour des apps web dans un intranet qui était dispo h24 mais le soir et week-end, c'étais leur service info interne qui assurait les astreintes.
Après, le cadre légal, c'est pas vraiment mon job…
Je pense aussi que tu me réponds comme si j'étais l'auteur du tout premier commentaire qui parle de l'allégorie de la prod qui tombe à 18h.
[^] # Re: rust
Posté par Bruno Michel (site web personnel) . Évalué à 4.
J'ai l'impression que vous ne parlez pas de la même chose. Pour toi, avoir une prod a l'air d'impliquer des SLA, et dans ce contexte, travailler en équipe est effectivement une obligation.
Mais, il existe d'autres contextes. Par exemple, flus est un service avec une seule personne derrière et ça reste parfaitement légal. Et si sa prod tombe le vendredi à 18h, je pense qu'il aura à cœur de la réparer rapidement, même s'il n'a aucune obligation.
[^] # Re: rust
Posté par barmic 🦦 . Évalué à 2.
Je ne connaissais pas flus merci pour le lien :) et oui effectivement c'est ce que je décris un peu plus haut.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: rust
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Parce qu'il n'y a pas de gtk/qt/tk/… en pur Rust ? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# diff, git, delta
Posté par Pol' uX (site web personnel) . Évalué à 1.
Pour info, git peut produire un tel diff en dehors de tout repo git.
Adhérer à l'April, ça vous tente ?
[^] # Re: diff, git, delta
Posté par claudex . Évalué à 5.
Regarde la différence, le diff git classique donne de la couleur mais pas de la coloration syntaxique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: diff, git, delta
Posté par benoar . Évalué à 2.
Un éditeur bien fait le fait normalement très bien aussi, cf. vimdiff par exemple.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.