Pour avoir aussi vécu la migration Python 2 vers 3 sur un gros volume de code, ce n'est finalement pas ça que je retient comme vrais problèmes de Python.
Je ne retiendrais même pas les soucis de performances (sauf calcul scientifique, mais là Python est qu'une glue, donc ça compte pas vraiment). Car si tu as besoin de vrais performances, tu ne prends pas Python, point. Heureusement ce n'es pas courant, donc je passe ce point là.
De mon point de vue Python a deux gros problèmes:
* besoin de gérer les dépendances au runtime, à la livraison sur la cible, et non pas à la compilation une fois pour toute.
* il est très, trop permissif. Si tu n'as pas été ultra rigoureux sur ce que tu autorise à utiliser et comment, avec une grosse équipe de dev qui mélange des seniors et des juniors, tu vas te retrouver avec des parties bien trop complexes pour pas grand chose, et les juniors qui vont se limiter à copier coller sans factoriser. Évidement tu as le problème avec tous les langages, mais en Python tu vas très vites dans les extrêmes vu qu'il ne te bloque en rien dans les deux directions.
Le premier point se règle à coup de Docker comme on l'a vu au fil des commentaires. Mais ça c'est quand on peut l’utiliser (heureusement c'est généralement le cas). Et ça marche très bien quand tu dois déployer sur ta propre infra/service, car tu maitrise l'environnement. Mais si tu dois livrer à des clients tiers, là les limites vont vite arriver.
Mais ça reste de la technique, donc on arrive à gérer. Le second problèmes lui est plus sournois et se voit au fil du temps. On va très vite en Python, donc c'est très rentable au début, mais le cout de maintenance peu vite devenir très problématique. Il faut donc dès le départ se garder de faire des choses trop complexes et tenter un maximum de rester "simple" quand un langage te permets autant de libertés.
Après tout est une question de contraintes et de choix, comme d'habitudes. Python n'est pas parfait dans tous les cas, mais dans certains il est excellent, et je ne parle pas que du calcul numérique, mais aussi pour gérer du code business mode "passe plat". Juste qu'il ne faut pas l'appliquer là où ça ne colle pas, mais bon comme d'habitude, si tu n'as que des développeurs Python sous la main, bah mieux vaut partir sur du Python même s'il est pas parfaitement adapté que aller vers du Go/Rust et te reprendre une phase d’apprentissage en termes de mois qui va peut être tuer ta boite/produit de toute manière.
# Oui, mais pas ce que je retiens comme vrais problèmes de Python
Posté par Jean Gabes (site web personnel) . En réponse au lien Difficile de recommander Python en production . Évalué à 4.
Pour avoir aussi vécu la migration Python 2 vers 3 sur un gros volume de code, ce n'est finalement pas ça que je retient comme vrais problèmes de Python.
Je ne retiendrais même pas les soucis de performances (sauf calcul scientifique, mais là Python est qu'une glue, donc ça compte pas vraiment). Car si tu as besoin de vrais performances, tu ne prends pas Python, point. Heureusement ce n'es pas courant, donc je passe ce point là.
De mon point de vue Python a deux gros problèmes:
* besoin de gérer les dépendances au runtime, à la livraison sur la cible, et non pas à la compilation une fois pour toute.
* il est très, trop permissif. Si tu n'as pas été ultra rigoureux sur ce que tu autorise à utiliser et comment, avec une grosse équipe de dev qui mélange des seniors et des juniors, tu vas te retrouver avec des parties bien trop complexes pour pas grand chose, et les juniors qui vont se limiter à copier coller sans factoriser. Évidement tu as le problème avec tous les langages, mais en Python tu vas très vites dans les extrêmes vu qu'il ne te bloque en rien dans les deux directions.
Le premier point se règle à coup de Docker comme on l'a vu au fil des commentaires. Mais ça c'est quand on peut l’utiliser (heureusement c'est généralement le cas). Et ça marche très bien quand tu dois déployer sur ta propre infra/service, car tu maitrise l'environnement. Mais si tu dois livrer à des clients tiers, là les limites vont vite arriver.
Mais ça reste de la technique, donc on arrive à gérer. Le second problèmes lui est plus sournois et se voit au fil du temps. On va très vite en Python, donc c'est très rentable au début, mais le cout de maintenance peu vite devenir très problématique. Il faut donc dès le départ se garder de faire des choses trop complexes et tenter un maximum de rester "simple" quand un langage te permets autant de libertés.
Après tout est une question de contraintes et de choix, comme d'habitudes. Python n'est pas parfait dans tous les cas, mais dans certains il est excellent, et je ne parle pas que du calcul numérique, mais aussi pour gérer du code business mode "passe plat". Juste qu'il ne faut pas l'appliquer là où ça ne colle pas, mais bon comme d'habitude, si tu n'as que des développeurs Python sous la main, bah mieux vaut partir sur du Python même s'il est pas parfaitement adapté que aller vers du Go/Rust et te reprendre une phase d’apprentissage en termes de mois qui va peut être tuer ta boite/produit de toute manière.