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.
# Huhu
Posté par Glandos . En réponse au lien Difficile de recommander Python en production . Évalué à 10.
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.