Je vais reprendre chacun des arguments du monsieur.
Les images pythons sont plus lourdes
Bah oui quand on sait pas les faire 😄
Son image Docker go fait 335 Mo ... quand on n'utilise pas le multi-stage (comme pour son exemple en Python)
J'ai moitié moins que lui (80 Mo) pour une image en Python similaire à la sienne en faisant les choses bien.
Mais oui, même à bonnes pratiques équivalents, Python perd sur ce critère là.
Sauf que là on parle d'une image, dès qu'il y a deux images, l'espace utilisée par la deuxième est grandement réduit en réutilisant les layers de la première, donc là encore ...
Et Python perds aussi pour l'utilisation des ressources et pour répondre bêtement du Hello World ...
Incroyable résultat à peine prévisible ...
Et en quoi c'est représentatif d'une application en production où bien souvent les temps d'attente viennent de la bdd ou du stockage ?
Le code Python est plus difficile à maintenir
Oui, si on ne sait pas coder dans ce language, c'est compliqué. Et oui, Python est un language plus permissif que Java. On fait moins de bêtises en étant pied et poing liés.
Le langage et les paquets sont difficiles à mettre à niveau
Un patch qui casse quelque chose, ça n'arrive que dans l'éco-système Python. Nul part ailleurs ...
On aurait eu le même problème avec un bug dans le binaire de la commande go.
Même l'outillage de développeurs Python ne préfère plus Python
UV est recommandé par ses utilisateurs, comme poetry est recommandé par ses utilisateurs ...
UV n'as rien d'officiel ou de plus mis en avant que d'autres (ça en revanche, c'est le gros problème de Python actuellement)
Quant à Ruff et Pydantic, oui ils sont en Rust mais pourquoi ?
Parce que c'est là où Rust excelle ! du parsing de string et de l'application de règles ! Aucune base de données, aucun service externe.
Et Rust est plus rapide que Python.
Python n'est pas le plus rapide, ni le plus léger des langages et il n'excelle que dans un domaine.
S'interconnecter avec d'autres langages et d'autres outils.
Et il est bon partout.
Venir attaquer Python sur un bench Hello World, c'est comme se plaindre du C++ qui nécessite une compilation pour s'exécuter ...
# Développeur Python en production ici 😉
Posté par Julien.D . En réponse au lien Difficile de recommander Python en production . Évalué à 10. Dernière modification le 08 mars 2025 à 16:38.
Je vais reprendre chacun des arguments du monsieur.
Bah oui quand on sait pas les faire 😄
Son image Docker go fait 335 Mo ... quand on n'utilise pas le multi-stage (comme pour son exemple en Python)
J'ai moitié moins que lui (80 Mo) pour une image en Python similaire à la sienne en faisant les choses bien.
Mais oui, même à bonnes pratiques équivalents, Python perd sur ce critère là.
Sauf que là on parle d'une image, dès qu'il y a deux images, l'espace utilisée par la deuxième est grandement réduit en réutilisant les layers de la première, donc là encore ...
Et Python perds aussi pour l'utilisation des ressources et pour répondre bêtement du Hello World ...
Incroyable résultat à peine prévisible ...
Et en quoi c'est représentatif d'une application en production où bien souvent les temps d'attente viennent de la bdd ou du stockage ?
Oui, si on ne sait pas coder dans ce language, c'est compliqué. Et oui, Python est un language plus permissif que Java. On fait moins de bêtises en étant pied et poing liés.
Un patch qui casse quelque chose, ça n'arrive que dans l'éco-système Python. Nul part ailleurs ...
On aurait eu le même problème avec un bug dans le binaire de la commande go.
UV est recommandé par ses utilisateurs, comme poetry est recommandé par ses utilisateurs ...
UV n'as rien d'officiel ou de plus mis en avant que d'autres (ça en revanche, c'est le gros problème de Python actuellement)
Quant à Ruff et Pydantic, oui ils sont en Rust mais pourquoi ?
Parce que c'est là où Rust excelle ! du parsing de string et de l'application de règles ! Aucune base de données, aucun service externe.
Et Rust est plus rapide que Python.
Python n'est pas le plus rapide, ni le plus léger des langages et il n'excelle que dans un domaine.
S'interconnecter avec d'autres langages et d'autres outils.
Et il est bon partout.
Venir attaquer Python sur un bench Hello World, c'est comme se plaindre du C++ qui nécessite une compilation pour s'exécuter ...