Comparer Python et Go en utilisant Docker, c'est huhuhu.
Sur ma Debian, si j'ai deux scripts Python, j'ai effectivement un gros stock de départ avec la bibliothèque standard. Et après, j'ai quelques octets par script.
Avec Go, c'est 10 Mo par binaire.
Parce que j'utilise pas cette gabegie de dépenses de ressources que représente Docker.
La qualité du code ne dépend clairement pas du langage. En plus, l'article présente Python comme un problème de qualité de code, tout en parlant juste au dessus de C++ pour les performances. C'est très paradoxal, écrire du bon code C++ est bien plus difficile que du bon code Python.
La gestion des dépendances en Python est connue pour être bordélique, mais au moins, y a un fichier pyproject.toml qui les listes toutes. La chaîne de dépendances est facilement analysable par un humain, au moins au premier niveau. En Go, il faut simplement lire chaque fichier, et lire les imports. Merci, c'est cool.
Et enfin, les outils, qui ne sont plus écrits en Python. Oui, ça fait longtemps que Python est utilisé pour faire du calcul numérique. Qui utilise numpy, qui n'est pas codé en Python. Ça fait longtemps que Python est utilisé pour faire du code d'entrée, afin de faire quelque chose de simple.
Je rajouterais que quand un binaire Go ne marche pas, c'est très compliqué de le patcher. En Python, on édite le fichier, ça marche.
Je conclus : j'aime beaucoup déployer des binaires en Go/Rust. C'est simple, ça marche, c'est rapide. Mais de là à jeter le Python en production pour ces arguments, c'est non recevable.
Je suis en phase avec tout ce que tu as dit avec un bémol sur
Comparer Python et Go en utilisant Docker, c'est huhuhu.
Sur ma Debian, si j'ai deux scripts Python, j'ai effectivement un gros stock de départ avec la bibliothèque standard. Et après, j'ai quelques octets par script.
L'auteur de l'article parle bien de production, il est quand même plus courant de déployer des services via Docker de nos jours que directement sur un serveur (Debian ou autres).
Donc, pour moi, ce point reste pertinent dans ce contexte.
Posté par Glandos .
Évalué à 5 (+4/-1).
Dernière modification le 08 mars 2025 à 15:33.
Alors, effectivement, si on part du principe qu'on a besoin de Docker pour déployer des services de production, chaque service prendra beaucoup de place. Même si, il me semble, Docker fonctionne sur le principe de couche avec OverlayFS, donc deux conteneurs utilisant la même base ne devrait pas prendre 2 fois l'espace disponible.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Ce que j'apprécie, et que l'auteur n'aime pas, c'est que justement, je mets à jour tout mon système d'un simple apt -U full-upgrade, et la sécurité est assurée. Si un conteneur Docker est affecté par une faille, il faut le cibler, et le mettre à jour « manuellement ». J'imagine qu'il y a des outils pour automatiser ça, mais ça revient à mon postulat de base : il faut plus de ressources pour utiliser Docker (un gros stockage pour les images, des outils d'automatisation). Et mon défaut, c'est de considérer que l'informatique n'a pas des ressources illimitées, et d'essayer de les économiser au maximum. Je deviens un peu chatouilleux sur le sujet :)
Justement, Docker permet de densifier les services de façon simple et plus sécurisée. In fine, Docker va te permettre de mettre un maximum de service sur ton infra avec un coût minimal pour ta couche d'abstraction (par rapport à de la virtualisation).
Si, tu veux gérer ça manuellement (pour ne pas dire à l'ancienne ;)), je te souhaite bon courage pour avoir un environnement qui conviendra à tous et spécialement avec les technos qui sont moins dans l'esprit du 12 factor.
C'est vrai, je ne parle pas spécialement de Python mais de conteneurisation, ici.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.
Posté par GwenLg .
Évalué à 8 (+7/-0).
Dernière modification le 08 mars 2025 à 12:52.
Context: je n'ai pas lu l'article, et je suis programmeur historiquement surtout C++ et aujourd'hui Rust
Mon expérience de Python en "production" c'est l'hébergement de Yunohost et Synapse (server matrix de référence).
Après une mise à jour de Synapse, l'envoie de photos ne fonctionnait plus. Après petite enquête dans les logs, il s'avère qu'une dépendance pour la gestion d'image avait été mise à jour, et que cette mise supprimait une fonction qui était marqué comme déprécié depuis un moment, et que le code de Synapse n'avait pas été mis à jour.
Que ce genre de problème puisse arriver jusqu'en production sans qu'au minimum un check de CI n'est levé une alerte me parais quand même problématique.
Peut-être qu'il y a des outils type analyseur static qui aurait pu/dû être utilisé en CI pour prévenir le problème. Mais rien que le fait que ce soit optionnel est un malus pour moi dans la confiance que je peux apporter à du code Python par rapport à du Go/Rust.
Si je dois héberger un service, je vais avoir tendance à chercher plutôt des outils écris dans des langages compilés plutôt qu'interprété comme premier filtre. Et si seulement je ne trouve rien qui correspond, je vais élargir la recherche.
Donc je suis plutôt d'accords avec l'idée "Difficile de recommander Python en production".
Vu mes expériences avec Python ces 15 dernières années, je ne peux qu'être d'accord avec l'article (et bien sûr en désaccord avec toi).
Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus.
Est-ce à cause du langage et du runtime python ? En partie je pense. Mais je pense aussi que le problème de python,c'est que la plupart de ceux qui en font ne sont pas formés à ça et se retrouvent à développer du code pourri, qui certes a lair de fonctionner, mais qui est difficile à maintenir ou se trouve lent à l'exécution parce que les gens qui ont développés ne se sont pas posés de questions.
J'ai vu ce genre de choses à chaque fois que j'ai du intervenir sur du code python. Des gros bloats avec des fonctions de plusieurs pages, avec du code sans cohérence (un bout de code pour faire un truc, suivi d'un bout de code pour faire autre chose, suivi d"'un autre bou de code pour continuer à faire ce qui avait été commencé précédemment, …). Puis bien sûr comme il n'y a pas de tests unitaires, c'est la galère pour tout reprendre …
Je ne parle pas des problèmes de dépendances, car l'article en a parlé (c'est d'ailleurs 90% des problèmes que je rencontre lorsque je veux installer un truc développé en python, mais on a parfois les mêmes soucis avec Ruby et ses gems).
Dernier détail : est-ce si difficile que ça de faire du packaging en python ? Parce que dernièrement je discutais d'un truc avec un dev : comme beaucoup de devs aujourd'hui, quand il package une appli, il la package dans une image docker, et moi ça me gène. En effet, l'appli devrait être, de mon point de vue, empaqueté dans un paquet python, avant d'être installée dans l'image via pip ( comme une appli Java est empaqueté dans un fichier Jar par exemple… mais il me dit que c'est se générer beaucoup de travail et des complexités pour rien. Pour beaucoup de langages modernes que je connais (Rust, Go, Java par exemple), c'est pas si compliqué que ça. En Ruby c'est un peu plus compliqué mais pas impossible. Et pour d'autres langages tels que C, on a des outils qui permettent de le faire facilement (dans l'absolu je pense qu'on pourrait même utiliser Maven pour faire un tgz, mais les outils de build couramment utilisés doivent permettre de le faire).
Puis bien sûr comme il n'y a pas de tests unitaires, c'est la galère pour tout reprendre …
Oui enfin n'importe quel projet sans test unitaire, c'est forcément galère a moins d'être sur une petite application.
Pour ma part, j'ai bien plus souvent constaté des projets où on disait "ça compile = c'est testé", et du coup on se passe de tests. Language compilé ou pas, rien ne remplace les tests.
Pour beaucoup de langages modernes que je connais (Rust, Go, Java par exemple), c'est pas si compliqué que ça.
Et c'est nécessaire pour ces languages, puisqu'ils sont compilés. Si le language n'est pas compilé, cette étape ne sert a rien => on l'enlève.
pip n'est pas aussi simple que ça. Tu dois utiliser un environnement virtuel, sinon il refuse de faire ce que tu lui demande. Et des façons d'en créer tu en as un nouveau tous les ans.
Tu peux aussi utiliser conda, tu peux partir sur un paquet binaire genre pyinstaller, certains utilisent nix ce qui peut être pratique si tu dépend d'une bibliothèque native,…
Je n'ai jamais vu quelqu'un copier les dépendances comme ça, je ne suis pas sûr que ce soit une excellente idée
Alors je parlais pas des dépendances, on parlait de livrer le projet en tant quel tel (et un projet qui ne soit pas une librairie python).
La recette typique d'un backend fait en python pour moi c'est :
je gère mes dépendances avec pip et virtualenv, ou autre surcouche (conda, poetry, pyenv, uv).
je fais un docker file a partir de python-slim, j'installe les dépendances avec mon outil surcouche a pip, et je copie les fichiers de mon projet a l'intérieur du container.
La discussion ici, elle portait sur le fait de fait de packager sa propre appli avec pip pour l'installer dans le container. Et ça a mon sens, c'est inutile car en python on a pas cette étape de compilation.
Comme je disais plus haut, cette façon de faire te permet de t'affranchir de l'environnement d'installation : tu peux autant l'installer sur une VM, un conteneur docker, un virtualenv, ou n'importe quoi via un pip install (jango par exemple, ou ansible s'installent ainsi), en plus d'être cohérent avec les méthodes de packaging de ton environnement/framework de développement.
Mais utiliser pip a l'intérieur d'un container docker, c'est un peu absurdement compliqué alors qu'on a juste besoin de copier des fichiers.
C'est là ou je ne suis pas d'accord : l'avantage de créer un package pip, c'est de rendre completement indépendant l'outil du mode de déploiement: que tu l'installes sur une vM, sur un serveur bare metal, dans une image docker, dans un virtualenv, ou n'importe ou, l'installation se résume à un pip install. Et dire que c'est compliqué je n'y crois pas trop (ou alors c'est que Python est encore plus pourri que je ne le pensais) : certes tu prends un peu de temps au début pour initialiser la créaton du package, mais ensuite tu mets ça en chaine de CI et on n'en parle quasiment plus.
Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus.
Mais je pense aussi que le problème de python, c'est que la plupart de ceux qui en font ne sont pas formés à ça et se retrouvent à développer du code pourri, qui certes a l'air de fonctionner, mais qui est difficile à maintenir ou se trouve lent à l'exécution parce que les gens qui ont développés ne se sont pas posés de questions.
Tu peux faire la même généralité1 pour PHP, c'est peut-être vrai mais au final peu important. Pourquoi ? Car la majorité des sites Internet n'ont pas besoin d'être hyper-performants ni de pouvoir monter en charge.
Malgré que ce soit un langage pour crétins décrié par les sachant·es, PHP fait tourner 80% des sites Internet dynamiques (dont une bonne proportion est Wordpress, un CMS à la réputation de bloatware scandaleux).
Les 20% des sites qui doivent être performants concentrent probablement plus de 90% du trafic. Et ces sites à forte charge ou chaque seconde de pages vues vaut des fortunes, ont besoin de code rapide et propre, en Go, Rust, .NET ou que sais-je, avec des CDN et des bases de données rapides. Et pour cette minorité de services, nous sommes d'accord.
Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus
Si c'est le cas, on peut se demander pourquoi Python est très utilisé pour les IA, dont Deepseek et OpenThinker-32B encore plus performant que Deepseek, écrits en Python.
OpenThinker-32B, developed by the Open Thoughts consortium, achieved a 90.6% accuracy score on the MATH500 benchmark, edging past DeepSeek's 89.4% https://github.com/open-thoughts/open-thoughts
Il semble plutôt que le Python est un très bon langage glue, c'est-à-dire qu'il fait la colle avec d'autres dépendances écrites en C ou autres qui feront les calculs/traitements.
Donc, pour moi, je pense que Python ne fait pas partie du chemin critique de l'application d'IA.
Je répondais concernant le titre "Difficile de recommander Python en production". Or, dans le cas des IA, c'est de la production et les devs des IA les plus performantes semblent préférer le Python à d'autres langages, ce n'est pas anodin. Questions bête: pourquoi?
Je ne suis pas expert mais il existe pourtant d'autres bibliothèques open source que les bibliothèques Python (puisqu'il s'agit d'IA présentées comme "open source": C, C++, Ruby, Rust, Haskell, Go, Lua, etc.
Mais, d'après ce que j'ai pu voir, la conception de l'IA c'est d'abord des maths, donc plutôt le boulot des mathématiciens et mathématiciennes donc de personnes qui sont plus familiarisées avec des outils comme Python.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Les maths déployés dans les projets de machine learning sont très compliqués. C'est extrêmement difficile à lire. On peut rester plusieurs jours coincés sur 10 lignes de code a vraiment comprendre ce que l'on fait.
Python apporte une syntaxe simple qui permet de se concentrer sur les concepts mathématiques sans perdre en performance grâce aux librairies pandas, numpy et autres.
S'il fallait faire la même chose dans des languages plus bas niveau, ce serait juste illisible.
C'est pour ça que je l'appelle le "visual Basic" du libre. Certains trouvent ça un peu dénigrant mais sur le fond, le BASIC c'était un peu lamême chose à l'époque : un langage simple permettant d'apprendre à programmer.
Posté par flagos .
Évalué à 3 (+1/-0).
Dernière modification le 09 mars 2025 à 12:49.
un langage simple permettant d'apprendre à programmer.
Je dirais plus que c'est un gain de productivité qui permet de faire dans un temps raisonnable des choses plus compliquées, que tu n'arriverais pas forcément a faire avec des langages plus laborieux, tout en maintenant une qualité de code raisonnable.
Ce qui en fait le language de prédilection pour coder de la business logic.
Pour confirmer ton argument : j'ai vu Python utilisé aussi dans des labos au CEA pour piloter des expériences de recherche en physique quantique. Python n'est pas spécialement temps réel, il s'agit d'un moyen simple pour des chercheuses et des chercheurs qui ne sont pas forcément des brutes en programmation de mettre au point leurs expériences. Derrière, il y a du R, du C, et des matériels très précis.
Il faut garder en tête que Python est un héritage de ABC, un langage simple pour apprendre à programmer. C'est une des raisons de sa popularité.
L'optimisation des paramètres du modèle ce n'est pas vraiment de la production. Le code python gère le script pour l'apprentissage et construit le graphe des opérations mathématiques à calculer. C'est un scénario qui se prête bien à python car la construction du graphe demande peu de ressources et de parallélisme, donc python ne devient pas un goulot d'étranglement. Mais c'est un cas d'usage assez spécifique en science et plus généralement en informatique.
En production le modèle est rechargé et exécuté par une librairie différente qui n'est pas nécessairement en python (ou juste avec des bindings python haut niveau).
Posté par Julien.D .
Évalué à 10 (+11/-3).
Dernière modification le 08 mars 2025 à 16:38.
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 …
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.
Tu as loupé la partie ou il dit "I started writing in the 2010s when Python 2 was going to be deprecated and Python 3 was too early to support" ?
C'est un grand écart que de déduire qu'il sait pas écrire du code python alors qu'il est sorti de la fac il y a quand même 15 ans.
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 ?
Et pour la consommation mémoire, c'est aussi le stockage et la bdd qui jouent, ou c'est simplement à ignorer dans la reprise de "chacun des arguments" ?
On peut aussi parler du temps de démarrage, une des raisons qui font que Mercurial a été refait en rust. Mercurial qui n'est pas juste un bench hello world, et qui n'a pas été écrit par des gens qui ne savent pas coder.
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.
Bah comme dit plus haut, c'est pas bon pour les hyperscalers, ou pour les gens prêts de leur sous. Je suis content de voir qu'Element a finalement corrigé la conso mémoire/cpu de synapse (une histoire de conversion de chaîne inutile, je retrouve pas l'annonce), mais comme je l'ai posté en 2021, c'était pas fameux du tout par rapport à du Rust ou du Go (et ça fait la différence de quelques euros par mois en terme de VM pour moi, et sans doute de quelques dizaines à centaines de milliers d'euros pour Element, vu qu'ils ont aussi du refaire des bouts de Synapse en rust.
Et comme le montre le cas de Mercurial (ou dnf/yum vs apt), c'est pas non plus terrible pour les CLIs (git est en C, et la vitesse de git m'a souvent été mise en avant comme avantage).
Ce qui fait que ça marche, c'est que n'importe qui peut l'apprendre (comme j'ai pu le voir à mon grand regret plus d'une fois en passant en second), donc ça a fini par remplacer perl en terme écosystème.
Venir attaquer Python sur un bench Hello World, c'est comme se plaindre du C++ qui nécessite une compilation pour s'exécuter …
Ce qui serait valable si il faut mesurer la simplicité d'apprentissage.
J'aurais dû en déduire quoi du fait qu'il a fait du Python en 2010 ?
Qu'il en fait depuis 15 ans ou qu'il n'y a pas toucher depuis 15 ans ?
En tout cas, il n'y a que 2 fois le mot Python dans son CV et uniquement dans des postes de CTO des 3 dernières années.
En tout cas son exemple Docker de python est fortement biaisé et c'est ça que je lui reproche dans la première partie de son article.
L'utilisation cpu ou ram, c'est le même constat, utiliser des outils plus haut niveau, c'est souvent moins optimisé.
Mercurial est encore une fois un bon exemple de projet où Python ne brille pas, comme je le disais pour Ruff ou Pydantic. Oui, pas de soucis pour dire ça.
En quoi c'est pas bon pour les hyperscalers ? Ils facturent à la ressource, le langage ne change rien, c'est aux clients de faire leurs comptes.
Résumer le budget d'un projet IT à sa consommation cpu/ram c'est … osé.
Le modèle de l'infra compte aussi beaucoup. Et les salaires :)
Et tout le monde n'est pas un GAFAM avec leurs besoins d'optimisation et de scalabilité.
Oui, Python n'est pas le langage le plus performant, mais delà à ne pas le recommandé en production …
C'est super que certains s'intéressent à la performance et choisissent leurs outils en fonction !
D'ailleurs pourquoi Python est si utilisée en data/ia si c'est si peu performant ?
Parce que c'est juste du binding vers du C ou autre.
Et c'est très bien comme ça !
On utilise Python pour les besoins généraux, et on fait du binding quand on a besoin de performance.
C'est plutôt bien que tout le monde puisse apprendre non ?
Les devs auraient peur que n'importe qui commence à utiliser vraiment l'informatique ? 😱
Donc par exemple apprendre la programmation à l'école, c'est forcément du C et rien d'autre ?
Je ne referais pas Git en Python, mais Python peut très bien faire des CLI. Encore une fois, c'est quand on a des besoins de performances qu'il faut se poser la question de déléguer certains calculs. C'est exactement le modèle du monde data/ia actuellement. Le meilleur outil pour chaque besoin.
Bref, encore ce débat de technophile sur "le vrai code, la vraie (et seule) méthode" …
Alors que l'éco-système est assez ouvert sur les autres langages, mais c'est peut-être ça qui dérange finalement 😄
J'ai pu comparer exactement les mêmes applications écrites en Python puis réécrites en Go en quasi copier-coller (c'est à dire pas en changeant en même temps de méthode).
J'ai fait ce choix à l'époque où il fallait de toutes façons faire évoluer des applications Py2 vers Py3.
Le déploiement, la maintenance et les évolutions ont été pour moi très largement facilités.
Je programmais en C avant Python, d'où une certaine facilité pour appréhender Go, je ne conseillerai pas forcément à tout le monde de faire la même chose !
Python a aussi un serveur HTTP dans la librairie standard :
fromhttp.serverimportBaseHTTPRequestHandler,HTTPServerclassHandler(BaseHTTPRequestHandler):defdo_GET(self):self.send_response(200)self.send_header('Content-type','text/plain')self.end_headers()self.wfile.write(b'hello world')if__name__=='__main__':server=HTTPServer(('localhost',8000),Handler)print('Server running on http://localhost:8000/')server.serve_forever()
Pas besoin d'installer FastAPI pour ça. L'image `python:3.13-alpine" fait 45Mo (18Mo compressée), pas 164Mo.
# Huhu
Posté par Glandos . Évalué à 10 (+10/-3).
Comparer Python et Go en utilisant Docker, c'est huhuhu.
Sur ma Debian, si j'ai deux scripts Python, j'ai effectivement un gros stock de départ avec la bibliothèque standard. Et après, j'ai quelques octets par script.
Avec Go, c'est 10 Mo par binaire.
Parce que j'utilise pas cette gabegie de dépenses de ressources que représente Docker.
La qualité du code ne dépend clairement pas du langage. En plus, l'article présente Python comme un problème de qualité de code, tout en parlant juste au dessus de C++ pour les performances. C'est très paradoxal, écrire du bon code C++ est bien plus difficile que du bon code Python.
La gestion des dépendances en Python est connue pour être bordélique, mais au moins, y a un fichier
pyproject.tomlqui les listes toutes. La chaîne de dépendances est facilement analysable par un humain, au moins au premier niveau. En Go, il faut simplement lire chaque fichier, et lire les imports. Merci, c'est cool.Et enfin, les outils, qui ne sont plus écrits en Python. Oui, ça fait longtemps que Python est utilisé pour faire du calcul numérique. Qui utilise numpy, qui n'est pas codé en Python. Ça fait longtemps que Python est utilisé pour faire du code d'entrée, afin de faire quelque chose de simple.
Je rajouterais que quand un binaire Go ne marche pas, c'est très compliqué de le patcher. En Python, on édite le fichier, ça marche.
Je conclus : j'aime beaucoup déployer des binaires en Go/Rust. C'est simple, ça marche, c'est rapide. Mais de là à jeter le Python en production pour ces arguments, c'est non recevable.
[^] # Re: Huhu
Posté par woffer 🐧 (site web personnel) . Évalué à 3 (+3/-0).
Je suis en phase avec tout ce que tu as dit avec un bémol sur
L'auteur de l'article parle bien de production, il est quand même plus courant de déployer des services via Docker de nos jours que directement sur un serveur (Debian ou autres).
Donc, pour moi, ce point reste pertinent dans ce contexte.
[^] # Re: Huhu
Posté par Misc (site web personnel) . Évalué à 5 (+3/-0).
Il y a eu 12 000 personnes pour Kubecon EU à Paris en 2024. PyCon US, à titre de comparaison, c'est 2700 tickets la même année.
On peut donc en effet difficilement dire que l'usage de conteneurs est minoritaire (ou en tout cas, par rapport à celui de Python).
[^] # Re: Huhu
Posté par Glandos . Évalué à 5 (+4/-1). Dernière modification le 08 mars 2025 à 15:33.
Alors, effectivement, si on part du principe qu'on a besoin de Docker pour déployer des services de production, chaque service prendra beaucoup de place. Même si, il me semble, Docker fonctionne sur le principe de couche avec OverlayFS, donc deux conteneurs utilisant la même base ne devrait pas prendre 2 fois l'espace disponible.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Ce que j'apprécie, et que l'auteur n'aime pas, c'est que justement, je mets à jour tout mon système d'un simple
apt -U full-upgrade, et la sécurité est assurée. Si un conteneur Docker est affecté par une faille, il faut le cibler, et le mettre à jour « manuellement ». J'imagine qu'il y a des outils pour automatiser ça, mais ça revient à mon postulat de base : il faut plus de ressources pour utiliser Docker (un gros stockage pour les images, des outils d'automatisation). Et mon défaut, c'est de considérer que l'informatique n'a pas des ressources illimitées, et d'essayer de les économiser au maximum. Je deviens un peu chatouilleux sur le sujet :)[^] # Re: Huhu
Posté par woffer 🐧 (site web personnel) . Évalué à 2 (+2/-1).
Justement, Docker permet de densifier les services de façon simple et plus sécurisée. In fine, Docker va te permettre de mettre un maximum de service sur ton infra avec un coût minimal pour ta couche d'abstraction (par rapport à de la virtualisation).
Si, tu veux gérer ça manuellement (pour ne pas dire à l'ancienne ;)), je te souhaite bon courage pour avoir un environnement qui conviendra à tous et spécialement avec les technos qui sont moins dans l'esprit du 12 factor.
C'est vrai, je ne parle pas spécialement de Python mais de conteneurisation, ici.
[^] # Re: Huhu
Posté par Misc (site web personnel) . Évalué à 6 (+3/-0).
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.
[^] # Re: Huhu
Posté par GwenLg . Évalué à 8 (+7/-0). Dernière modification le 08 mars 2025 à 12:52.
Context: je n'ai pas lu l'article, et je suis programmeur historiquement surtout C++ et aujourd'hui Rust
Mon expérience de Python en "production" c'est l'hébergement de Yunohost et Synapse (server matrix de référence).
Après une mise à jour de Synapse, l'envoie de photos ne fonctionnait plus. Après petite enquête dans les logs, il s'avère qu'une dépendance pour la gestion d'image avait été mise à jour, et que cette mise supprimait une fonction qui était marqué comme déprécié depuis un moment, et que le code de Synapse n'avait pas été mis à jour.
Que ce genre de problème puisse arriver jusqu'en production sans qu'au minimum un check de CI n'est levé une alerte me parais quand même problématique.
Peut-être qu'il y a des outils type
analyseur staticqui aurait pu/dû être utilisé en CI pour prévenir le problème. Mais rien que le fait que ce soit optionnel est un malus pour moi dans la confiance que je peux apporter à du code Python par rapport à du Go/Rust.Si je dois héberger un service, je vais avoir tendance à chercher plutôt des outils écris dans des langages compilés plutôt qu'interprété comme premier filtre. Et si seulement je ne trouve rien qui correspond, je vais élargir la recherche.
Donc je suis plutôt d'accords avec l'idée "Difficile de recommander Python en production".
[^] # Re: Huhu
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+7/-1). Dernière modification le 08 mars 2025 à 13:48.
Patcher directement sur la prod? Effectivement, j'ai pas super envie de recommander ça !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 9 (+7/-0).
Vu mes expériences avec Python ces 15 dernières années, je ne peux qu'être d'accord avec l'article (et bien sûr en désaccord avec toi).
Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus.
Est-ce à cause du langage et du runtime python ? En partie je pense. Mais je pense aussi que le problème de python,c'est que la plupart de ceux qui en font ne sont pas formés à ça et se retrouvent à développer du code pourri, qui certes a lair de fonctionner, mais qui est difficile à maintenir ou se trouve lent à l'exécution parce que les gens qui ont développés ne se sont pas posés de questions.
J'ai vu ce genre de choses à chaque fois que j'ai du intervenir sur du code python. Des gros bloats avec des fonctions de plusieurs pages, avec du code sans cohérence (un bout de code pour faire un truc, suivi d'un bout de code pour faire autre chose, suivi d"'un autre bou de code pour continuer à faire ce qui avait été commencé précédemment, …). Puis bien sûr comme il n'y a pas de tests unitaires, c'est la galère pour tout reprendre …
Je ne parle pas des problèmes de dépendances, car l'article en a parlé (c'est d'ailleurs 90% des problèmes que je rencontre lorsque je veux installer un truc développé en python, mais on a parfois les mêmes soucis avec Ruby et ses gems).
Dernier détail : est-ce si difficile que ça de faire du packaging en python ? Parce que dernièrement je discutais d'un truc avec un dev : comme beaucoup de devs aujourd'hui, quand il package une appli, il la package dans une image docker, et moi ça me gène. En effet, l'appli devrait être, de mon point de vue, empaqueté dans un paquet python, avant d'être installée dans l'image via pip ( comme une appli Java est empaqueté dans un fichier Jar par exemple… mais il me dit que c'est se générer beaucoup de travail et des complexités pour rien. Pour beaucoup de langages modernes que je connais (Rust, Go, Java par exemple), c'est pas si compliqué que ça. En Ruby c'est un peu plus compliqué mais pas impossible. Et pour d'autres langages tels que C, on a des outils qui permettent de le faire facilement (dans l'absolu je pense qu'on pourrait même utiliser Maven pour faire un tgz, mais les outils de build couramment utilisés doivent permettre de le faire).
[^] # Re: Huhu
Posté par flagos . Évalué à 6 (+4/-0).
Oui enfin n'importe quel projet sans test unitaire, c'est forcément galère a moins d'être sur une petite application.
Pour ma part, j'ai bien plus souvent constaté des projets où on disait "ça compile = c'est testé", et du coup on se passe de tests. Language compilé ou pas, rien ne remplace les tests.
Et c'est nécessaire pour ces languages, puisqu'ils sont compilés. Si le language n'est pas compilé, cette étape ne sert a rien => on l'enlève.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 2 (+0/-0).
Et pourqui ne sert-elle à rien ?
[^] # Re: Huhu
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C’est pas plutôt le contraire python a 125 manière d’être packager ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Huhu
Posté par flagos . Évalué à 2 (+0/-0). Dernière modification le 09 mars 2025 à 08:24.
Oui c'est un peu comme peu les distrib linux et leur système de paquets :-p
Troll a part, non aujourd'hui tu packages avec pip et c'est bon, tout le monde sait t'installer, par exemple en tant que dépendance.
Si on parle d'installer/déployer un binaire, soit tu utilises pip, soit tu utilises docker.
Mais utiliser pip a l'intérieur d'un container docker, c'est un peu absurdement compliqué alors qu'on a juste besoin de copier des fichiers.
[^] # Re: Huhu
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
pip n'est pas aussi simple que ça. Tu dois utiliser un environnement virtuel, sinon il refuse de faire ce que tu lui demande. Et des façons d'en créer tu en as un nouveau tous les ans.
Tu peux aussi utiliser conda, tu peux partir sur un paquet binaire genre pyinstaller, certains utilisent nix ce qui peut être pratique si tu dépend d'une bibliothèque native,…
Et docker fait grincer des dents certains https://linuxfr.org/forums/programmation-python/posts/livrer-un-environnement-python#comment-1977128
Quand on voit l'essai en 4 chapitre sur le sujet qui était sorti en dépêche ça paraît être de l'art https://linuxfr.org/news/l-installation-et-la-distribution-de-paquets-python-1-4
Python est un super langage mais la complexité de cette partie n'est clairement pas complètement résolue.
Je n'ai jamais vu quelqu'un copier les dépendances comme ça, je ne suis pas sûr que ce soit une excellente idée
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Huhu
Posté par flagos . Évalué à 2 (+0/-0).
Alors je parlais pas des dépendances, on parlait de livrer le projet en tant quel tel (et un projet qui ne soit pas une librairie python).
La recette typique d'un backend fait en python pour moi c'est :
La discussion ici, elle portait sur le fait de fait de packager sa propre appli avec pip pour l'installer dans le container. Et ça a mon sens, c'est inutile car en python on a pas cette étape de compilation.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 2 (+0/-0).
Comme je disais plus haut, cette façon de faire te permet de t'affranchir de l'environnement d'installation : tu peux autant l'installer sur une VM, un conteneur docker, un virtualenv, ou n'importe quoi via un pip install (jango par exemple, ou ansible s'installent ainsi), en plus d'être cohérent avec les méthodes de packaging de ton environnement/framework de développement.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 3 (+1/-0).
Moi je le vois tous les jours … et je suis convaincu que c'est une très mauvaise idée.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 2 (+0/-0).
C'est là ou je ne suis pas d'accord : l'avantage de créer un package pip, c'est de rendre completement indépendant l'outil du mode de déploiement: que tu l'installes sur une vM, sur un serveur bare metal, dans une image docker, dans un virtualenv, ou n'importe ou, l'installation se résume à un pip install. Et dire que c'est compliqué je n'y crois pas trop (ou alors c'est que Python est encore plus pourri que je ne le pensais) : certes tu prends un peu de temps au début pour initialiser la créaton du package, mais ensuite tu mets ça en chaine de CI et on n'en parle quasiment plus.
[^] # Re: Huhu
Posté par flagos . Évalué à 2 (+0/-0).
Et comment tu gères les dépendances sur packages systèmes avec uniquement pip ?
[^] # Re: Huhu
Posté par David Delassus (site web personnel) . Évalué à 2 (+0/-0).
De mon expérience personnelle et professionnelle avec Python, c'est quand même rare que ça arrive.
Et quand ça arrive, ben on fait pas, on fait un
apt installavant lepip install. Le dev le fait sur sa machine, l'ops le fait dans son Dockerfile.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Huhu
Posté par cg . Évalué à 3 (+1/-0).
Tu peux faire la même généralité1 pour PHP, c'est peut-être vrai mais au final peu important. Pourquoi ? Car la majorité des sites Internet n'ont pas besoin d'être hyper-performants ni de pouvoir monter en charge.
Malgré que ce soit un langage
pour crétinsdécrié par les sachant·es, PHP fait tourner 80% des sites Internet dynamiques (dont une bonne proportion est Wordpress, un CMS à la réputation de bloatware scandaleux).Les 20% des sites qui doivent être performants concentrent probablement plus de 90% du trafic. Et ces sites à forte charge ou chaque seconde de pages vues vaut des fortunes, ont besoin de code rapide et propre, en Go, Rust, .NET ou que sais-je, avec des CDN et des bases de données rapides. Et pour cette minorité de services, nous sommes d'accord.
un peu pédante si tu veux mon avis :p ↩
[^] # Re: Huhu
Posté par Maderios . Évalué à 3 (+1/-0).
Si c'est le cas, on peut se demander pourquoi Python est très utilisé pour les IA, dont Deepseek et OpenThinker-32B encore plus performant que Deepseek, écrits en Python.
[^] # Re: Huhu
Posté par woffer 🐧 (site web personnel) . Évalué à 6 (+5/-0).
Il semble plutôt que le Python est un très bon langage glue, c'est-à-dire qu'il fait la colle avec d'autres dépendances écrites en C ou autres qui feront les calculs/traitements.
Donc, pour moi, je pense que Python ne fait pas partie du chemin critique de l'application d'IA.
[^] # Re: Huhu
Posté par Maderios . Évalué à 2 (+0/-0).
Je répondais concernant le titre "Difficile de recommander Python en production". Or, dans le cas des IA, c'est de la production et les devs des IA les plus performantes semblent préférer le Python à d'autres langages, ce n'est pas anodin. Questions bête: pourquoi?
[^] # Re: Huhu
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
L'une des réponses possibles, en tant que béotienne, c'est qu'il y a des bibliothèques Python pour ça.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Huhu
Posté par Maderios . Évalué à 2 (+0/-0).
Je ne suis pas expert mais il existe pourtant d'autres bibliothèques open source que les bibliothèques Python (puisqu'il s'agit d'IA présentées comme "open source": C, C++, Ruby, Rust, Haskell, Go, Lua, etc.
[^] # Re: Huhu
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Mais, d'après ce que j'ai pu voir, la conception de l'IA c'est d'abord des maths, donc plutôt le boulot des mathématiciens et mathématiciennes donc de personnes qui sont plus familiarisées avec des outils comme Python.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Huhu
Posté par Maderios . Évalué à 2 (+0/-0).
Tout à fait
[^] # Re: Huhu
Posté par flagos . Évalué à 4 (+2/-0).
Ce n'est pas qu'une question d'habitude.
Les maths déployés dans les projets de machine learning sont très compliqués. C'est extrêmement difficile à lire. On peut rester plusieurs jours coincés sur 10 lignes de code a vraiment comprendre ce que l'on fait.
Python apporte une syntaxe simple qui permet de se concentrer sur les concepts mathématiques sans perdre en performance grâce aux librairies pandas, numpy et autres.
S'il fallait faire la même chose dans des languages plus bas niveau, ce serait juste illisible.
[^] # Re: Huhu
Posté par totof2000 . Évalué à 1 (+0/-1).
C'est pour ça que je l'appelle le "visual Basic" du libre. Certains trouvent ça un peu dénigrant mais sur le fond, le BASIC c'était un peu lamême chose à l'époque : un langage simple permettant d'apprendre à programmer.
[^] # Re: Huhu
Posté par flagos . Évalué à 3 (+1/-0). Dernière modification le 09 mars 2025 à 12:49.
Je dirais plus que c'est un gain de productivité qui permet de faire dans un temps raisonnable des choses plus compliquées, que tu n'arriverais pas forcément a faire avec des langages plus laborieux, tout en maintenant une qualité de code raisonnable.
Ce qui en fait le language de prédilection pour coder de la business logic.
[^] # Re: Huhu
Posté par cg . Évalué à 4 (+2/-0).
Pour confirmer ton argument : j'ai vu Python utilisé aussi dans des labos au CEA pour piloter des expériences de recherche en physique quantique. Python n'est pas spécialement temps réel, il s'agit d'un moyen simple pour des chercheuses et des chercheurs qui ne sont pas forcément des brutes en programmation de mettre au point leurs expériences. Derrière, il y a du R, du C, et des matériels très précis.
Il faut garder en tête que Python est un héritage de ABC, un langage simple pour apprendre à programmer. C'est une des raisons de sa popularité.
[^] # Re: Huhu
Posté par nlgranger . Évalué à 2 (+1/-0).
L'optimisation des paramètres du modèle ce n'est pas vraiment de la production. Le code python gère le script pour l'apprentissage et construit le graphe des opérations mathématiques à calculer. C'est un scénario qui se prête bien à python car la construction du graphe demande peu de ressources et de parallélisme, donc python ne devient pas un goulot d'étranglement. Mais c'est un cas d'usage assez spécifique en science et plus généralement en informatique.
En production le modèle est rechargé et exécuté par une librairie différente qui n'est pas nécessairement en python (ou juste avec des bindings python haut niveau).
# Développeur Python en production ici 😉
Posté par Julien.D . Évalué à 10 (+11/-3). 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 …
[^] # Re: Développeur Python en production ici 😉
Posté par Misc (site web personnel) . Évalué à 7 (+5/-1).
Tu as loupé la partie ou il dit "I started writing in the 2010s when Python 2 was going to be deprecated and Python 3 was too early to support" ?
C'est un grand écart que de déduire qu'il sait pas écrire du code python alors qu'il est sorti de la fac il y a quand même 15 ans.
Et pour la consommation mémoire, c'est aussi le stockage et la bdd qui jouent, ou c'est simplement à ignorer dans la reprise de "chacun des arguments" ?
On peut aussi parler du temps de démarrage, une des raisons qui font que Mercurial a été refait en rust. Mercurial qui n'est pas juste un bench hello world, et qui n'a pas été écrit par des gens qui ne savent pas coder.
Bah comme dit plus haut, c'est pas bon pour les hyperscalers, ou pour les gens prêts de leur sous. Je suis content de voir qu'Element a finalement corrigé la conso mémoire/cpu de synapse (une histoire de conversion de chaîne inutile, je retrouve pas l'annonce), mais comme je l'ai posté en 2021, c'était pas fameux du tout par rapport à du Rust ou du Go (et ça fait la différence de quelques euros par mois en terme de VM pour moi, et sans doute de quelques dizaines à centaines de milliers d'euros pour Element, vu qu'ils ont aussi du refaire des bouts de Synapse en rust.
Et comme le montre le cas de Mercurial (ou dnf/yum vs apt), c'est pas non plus terrible pour les CLIs (git est en C, et la vitesse de git m'a souvent été mise en avant comme avantage).
Ce qui fait que ça marche, c'est que n'importe qui peut l'apprendre (comme j'ai pu le voir à mon grand regret plus d'une fois en passant en second), donc ça a fini par remplacer perl en terme écosystème.
Ce qui serait valable si il faut mesurer la simplicité d'apprentissage.
[^] # Re: Développeur Python en production ici 😉
Posté par Julien.D . Évalué à 3 (+2/-1).
J'aurais dû en déduire quoi du fait qu'il a fait du Python en 2010 ?
Qu'il en fait depuis 15 ans ou qu'il n'y a pas toucher depuis 15 ans ?
En tout cas, il n'y a que 2 fois le mot Python dans son CV et uniquement dans des postes de CTO des 3 dernières années.
En tout cas son exemple Docker de python est fortement biaisé et c'est ça que je lui reproche dans la première partie de son article.
L'utilisation cpu ou ram, c'est le même constat, utiliser des outils plus haut niveau, c'est souvent moins optimisé.
Mercurial est encore une fois un bon exemple de projet où Python ne brille pas, comme je le disais pour Ruff ou Pydantic. Oui, pas de soucis pour dire ça.
En quoi c'est pas bon pour les hyperscalers ? Ils facturent à la ressource, le langage ne change rien, c'est aux clients de faire leurs comptes.
Résumer le budget d'un projet IT à sa consommation cpu/ram c'est … osé.
Le modèle de l'infra compte aussi beaucoup. Et les salaires :)
Et tout le monde n'est pas un GAFAM avec leurs besoins d'optimisation et de scalabilité.
Oui, Python n'est pas le langage le plus performant, mais delà à ne pas le recommandé en production …
C'est super que certains s'intéressent à la performance et choisissent leurs outils en fonction !
D'ailleurs pourquoi Python est si utilisée en data/ia si c'est si peu performant ?
Parce que c'est juste du binding vers du C ou autre.
Et c'est très bien comme ça !
On utilise Python pour les besoins généraux, et on fait du binding quand on a besoin de performance.
C'est plutôt bien que tout le monde puisse apprendre non ?
Les devs auraient peur que n'importe qui commence à utiliser vraiment l'informatique ? 😱
Donc par exemple apprendre la programmation à l'école, c'est forcément du C et rien d'autre ?
Je ne referais pas Git en Python, mais Python peut très bien faire des CLI. Encore une fois, c'est quand on a des besoins de performances qu'il faut se poser la question de déléguer certains calculs. C'est exactement le modèle du monde data/ia actuellement. Le meilleur outil pour chaque besoin.
Bref, encore ce débat de technophile sur "le vrai code, la vraie (et seule) méthode" …
Alors que l'éco-système est assez ouvert sur les autres langages, mais c'est peut-être ça qui dérange finalement 😄
# De Python à Go
Posté par wilk . Évalué à 8 (+6/-0).
J'ai pu comparer exactement les mêmes applications écrites en Python puis réécrites en Go en quasi copier-coller (c'est à dire pas en changeant en même temps de méthode).
J'ai fait ce choix à l'époque où il fallait de toutes façons faire évoluer des applications Py2 vers Py3.
Le déploiement, la maintenance et les évolutions ont été pour moi très largement facilités.
Je programmais en C avant Python, d'où une certaine facilité pour appréhender Go, je ne conseillerai pas forcément à tout le monde de faire la même chose !
# Exemple pas comparable
Posté par David Delassus (site web personnel) . Évalué à 6 (+4/-0).
Python a aussi un serveur HTTP dans la librairie standard :
Pas besoin d'installer FastAPI pour ça. L'image `python:3.13-alpine" fait 45Mo (18Mo compressée), pas 164Mo.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Exemple pas comparable
Posté par flagos . Évalué à 4 (+2/-0). Dernière modification le 09 mars 2025 à 08:43.
Et ses performances sont d'ailleurs très bonnes, je me souviens l'avoir mesuré et poste un commentaire lors d'un journal sur un serveur java.
Edit: je l'ai retrouvé https://linuxfr.org/nodes/127979/comments/1893260
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.