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.
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.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
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.
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)
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.
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).
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.
[^] # Re: rust
Posté par barmic 🦦 . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. É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