Discussion :

[Bruno]

Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon

Jos Visser, ingénieur principal chez Amazon, critique le choix de Python comme langage de programmation pour les développeurs débutants. Il affirme que Python est un langage interprété, dynamique et qui ne garantit pas la sécurité du type ni la fiabilité du code. Il raconte ses expériences négatives avec de grandes applications Python, qui ont généré des erreurs et des exceptions imprévisibles. Visser soutient que Python est inadapté à la plupart des usages professionnels et qu’il faut lui préférer des langages compilés et sûrs du point de vue du type, comme Rust. Il donne l’exemple d’une réécriture réussie d’un système en Rust, qui a amélioré la performance et la stabilité de l’application.

Jos Visser, ingénieur principal chez Amazon, exprime son opinion négative sur Python, un langage de programmation très populaire. Il explique pourquoi il pense que Python est inutile pour la plupart des usages professionnels et qu’il faut lui préférer des langages plus adaptés. Il commence par réagir à un post LinkedIn qui conseillait aux développeurs débutants d’apprendre Python pour trouver un emploi. Il reconnaît que Python est un langage très demandé, mais il affirme que c’est un problème qui freine le progrès de l’industrie informatique. Il se base sur son expérience personnelle avec de grandes applications écrites en Python, qu’il compare à des réacteurs nucléaires construits avec des briques Lego. Il décrit les difficultés et les risques liés à la maintenance et à l’évolution de ces applications, qui sont souvent instables et imprévisibles.

Il identifie le problème principal de Python comme étant son caractère interprété, dynamique et en canard. Il explique que cela signifie que le code Python n’est pas vérifié avant l’exécution et qu’il peut produire des erreurs ou des exceptions selon les données qu’il reçoit. Il souligne que cela impose aux développeurs d’avoir une discipline rigoureuse pour contrôler toutes les données d’entrée, ce qui est rarement le cas dans la pratique. Il critique également le typage en canard de Python, qui permet d’écrire du code intelligent mais inutile, qui se retourne contre les développeurs.

Il raconte ses expériences négatives avec de grosses applications Python, qui ont généré des erreurs et des exceptions imprévisibles. Il donne l’exemple d’une application qui lançait du code qui n’avait jamais été testé ni exécuté auparavant. Il dit qu’il a réussi à convaincre son organisation de réécrire son système en Rust, un langage compilé et sûr du point de vue du type, qui a amélioré la performance et la stabilité de l’application.

Il conclut en réfutant l’argument selon lequel le problème ne vient pas de Python, mais de la stratégie de révision et de test du code. Il affirme que c’est une illusion de penser qu’il est possible d’examiner et de tester toutes les possibilités du code Python. Il défend la valeur d’un bon langage de programmation, qui garantit qu’un grand nombre d’erreurs ne peuvent pas se produire. Il suggère donc aux développeurs débutants de choisir un langage plus fiable et performant que Python pour leurs projets professionnels.

Les forces et les faiblesses de Python et de Rust pour la programmation système et l’apprentissage automatique

Python est un langage de programmation puissant qui offre de nombreux avantages, mais il faut aussi considérer plusieurs aspects quand on le compare à Rust pour la programmation système. Python est le langage préféré de beaucoup de développeurs, car il dispose d’un large éventail de bibliothèques, d’outils et de frameworks. Le langage conçu par Guido van Rossum a un écosystème riche, avec des bibliothèques performantes (comme NumPy, Pandas, scikit-learn) et des frameworks de ML éprouvés (comme TensorFlow, PyTorch) qui le rendent très productif pour le développement de modèles d’apprentissage automatique.

Python est aussi un langage lisible et facile à utiliser, qui permet de prototyper, d’expérimenter et d’itérer rapidement, ce qui est essentiel dans les premières phases du développement. La communauté Python fournit de nombreuses ressources, tutoriels et forums dédiés à l’apprentissage automatique, ce qui facilite la résolution de problèmes courants et la collaboration avec d’autres praticiens.

Par contre, Rust a des contrôles stricts à la compilation et des caractéristiques de sécurité de la mémoire qui le protègent des erreurs de programmation fréquentes comme les pointeurs nuls, les débordements de mémoire tampon et les courses de données. Ce niveau de sécurité peut être crucial lors du déploiement des projets professionnels en production, en assurant la stabilité et en réduisant le risque d’erreurs d’exécution ou de plantages. Rust est aussi interopérable avec C et Python, ce qui permet une intégration facile avec les bases de code Python existantes.

En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels.

Sources : Jos Visser's blog post, Karun Thankachan's blog post

Et vous ?

L'analyse de Jos Visser est-elle pertinente ?

Comment Jos Visser explique-t-il la popularité continue de Python malgré ses supposés défauts ?

Quels sont les avantages et les inconvénients de Python par rapport à des langages compilés et sûrs du point de vue du type, comme C++, Java ou Go ?

Voir aussi :

99% des principaux paquets Python sont maintenant des wheels, ce qui rendra plus rapide l'installation pour les paquets purement Python

Microsoft vient d'annoncer les améliorations Juillet 2023 de l'extension Python pour Visual Studio Code

Python 3.12.0b1, la première des quatre versions bêta de la 3.12, a été publiée et apporte de nouvelles fonctionnalités ainsi que des corrections de bogues

[wiztricks]

Salut,

Techniquement, il est difficile de comparer Rust à C++ mais pas à Python car on n'écrira pas les mêmes applications avec. Et je trouve le bonhomme un peu de mauvaise foi car beaucoup d'efforts ont été fait côté typage et analyse statique de code permettant à Python d'être utilisable dans des projets industriels.
Ceci dit pour les applications à mission critique, on préfèrera des langages encore plus robustes que Rust.

Maintenant il est clair que l'industrie informatique privilégie en général les coûts.
De ce fait, tout programmer avec un seul langage est un atout (pour moins bien payer les programmeurs puisqu'on en trouvera plein...)
Ses critiques contre un langage de programmation dominant ne sont pas nouvelles... A d'autres époques, on a connu java, php, basic... difficile de trouver du boulot sans les connaître.

Mais on adresse alors plutôt la myopie de nombre de décideurs car techniquement on ne va jamais utiliser le même langage pour tout.

- W

[Pyramidev]

Techniquement, il est difficile de comparer Rust à C++ mais pas à Python car on n'écrira pas les mêmes applications avec.

Des fois, si. Au fur et à mesure que l'écosystème de Rust progresse, il y a de plus en plus de code Python pour lequel Rust devient une alternative crédible.

Par exemple, Python est utilisé dans plusieurs entreprises pour du développement web backend, par exemple avec Django et FastAPI. Rust a aussi des crates qui ont le même rôle que FastAPI, les plus populaires étant axum et Actix Web. Pour les interactions avec les bases de données, il y a aussi des crates dédiés.

À part ça, dans le tooling et les packages Python, Rust progresse. Par exemple, Pydantic V1 était écrit en pur Python et compilé avec Cython, tandis que Pydantic V2 contient du Rust dans son implémentation (via pydantic-core) pour augmenter les performances.

Et je trouve le bonhomme un peu de mauvaise foi car beaucoup d'efforts ont été fait côté typage et analyse statique de code permettant à Python d'être utilisable dans des projets industriels.

Effectivement, tel que Jos Visser a formulé son article, il ne semble pas au courant de l'existence du typage statique optionnel en Python, qui existe pourtant depuis longtemps.

En pratique, les développeurs Python, utilisent-ils les annotations de type quand il est pertinent de les utiliser ? Des fois oui, des fois non. Cela dépend qui code. J'ai vu les deux cas.

[binarygirl]

C'est l'éternel débat langage compilé/interprété.
Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

On pourrait certes argumenter que les langages comme PHP, Python etc sont abordables pour les débutants, et donc il est courant de trouver du code de mauvaise qualité, ce qui explique le mauvais retour d'expérience dans le cas présent.

Effectivement, tel que Jos Visser a formulé son article, il ne semble pas au courant de l'existence du typage statique optionnel en Python, qui existe pourtant depuis longtemps.

Si on parle du type hinting, des annotations, il me semble que ça ne change pas le fait que Python reste dynamiquement typé et alors ce n'est pas du vrai typage statique au sens où ça existe dans d'autres langages. Mais on peut quand même utiliser des outils comme MyPy pour tester la cohérence du code. Et un bon IDE devrait déjà attirer l'attention sur certains problèmes.

Pour ce qui est des fuites mémoire, on peut utiliser un outil comme Valgrind. Idéalement, toutes ces batteries de tests devraient être mises en place dans une chaîne CI/CD, ce qui prend du temps.

[Eric80]

Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

On pourrait certes argumenter que les langages comme PHP, Python etc sont abordables pour les débutants, et donc il est courant de trouver du code de mauvaise qualité, ce qui explique le mauvais retour d'expérience dans le cas présent.


Si on parle du type hinting, des annotations, il me semble que ça ne change pas le fait que Python reste dynamiquement typé et alors ce n'est pas du vrai typage statique au sens où ça existe dans d'autres langages. Mais on peut quand même utiliser des outils comme MyPy pour tester la cohérence du code. Et un bon IDE devrait déjà attirer l'attention sur certains problèmes.

Pour ce qui est des fuites mémoire, on peut utiliser un outil comme Valgrind. Idéalement, toutes ces batteries de tests devraient être mises en place dans une chaîne CI/CD, ce qui prend du temps.

+1 sur les tests.
pour pas mal bosser en Python, Go, C# en milieu professionnel, je vois passer bcp d erreurs de code en Python qui n apparaissent qu'au Runtime alors que VS aurait déjà évité certaines en C#/.NET.

La flexibilité de Python doit s accompagner de plus de tests qu un équivalent en C# ou Go, et c est souvent là que cela pèche: Python est choisi pour son côté "proto" mais trop de dev se refusent à écrire tout les unit tests nécessaires pour rendre le code "professionnel grade / production ready".


Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".
J'ai vu trop de fois j ai vu du code style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

str(len(project["propA"]["subPropB"]))

sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if project and "propA" in project and "subPropB" in project["propA"]:

(En C# ou Go, l erreur serait la même, mais VS émet qques warning ici il me semble)

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

str(len(project["propA"]["subPropB"]))

sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if project and "propA" in project and "subPropB" in project["propA"]:

Pardon mais là je suis pas trop d'accord. Si j'écris traite dico["xxx"] c'est que je me sens à priori assez hardi dans le fait que quelque part plus haut j'ai écrit dico["xxx"]=valeur_à_traiter.
Et si je ne suis pas confiant dans mon Alzheimer, je peux toujours écrire traite dico.get("xxx", "valeur_sinon").

Parce que c'est bien joli d'écrire if project and "propA" in project and "subPropB" in project["propA"] style "je pense à tout" mais il faut alors vraiment penser à tout et donc aussi réfléchir à ce qui se passe dans le "else"...

[Eric80]

ds mon exemple, il s'agit de lire des valeurs d un fichier json transformée en dictionnaire avec les noeuds json. (d un json.load). J aurais du le préciser pour éviter toute incompréhension.
Donc aucune garantie que les valeurs existent. Et si elles n existent pas, il faut simplement ignorer le noeud parent. D'où le if and in proposé.

Si python propose une façon simple et puissante de charger un json, je préfère ce que je fait généralement en C# avec une approche 100% objet et une flopée de classes générées, avec un deserialize<myRootNodeClass>(jsonString) comme décrit dans la doc MS. Alors oui c est bcp plus long et verbeux mais AMHA plus facile à débugger et tester.

Dans tout les cas, je trouve que c est un bon ex de la puissance de Python. Ma critique va d'abord aux développeurs qui n ont pas tjs conscience des effets de bords possible...

[wiztricks]

Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".

Faut-il blâmer les développeurs ou ceux qui les emploient (et qui laissent faire)?
De toutes façons, il n'est pas facile de devenir "bon". On peut avoir une formation initiale raisonnable, mais si on n'a pas l'opportunité de bosser dans des équipes pour apprendre des plus anciens, difficile de s'améliorer seul dans son coin.
Tout l'intérêt de la qualité d'un développement est dans la compréhension d'un travail d'équipe. On écrit du code qui devra pouvoir être relu/maintenu par d'autres.
Et pour des applications critiques, on préférera faire faire le contrôle qualité par une autre entité que celle qui développe (on évite les conflits d'intérêt qui pourraient fermer les yeux sur certains défauts).

- W

[binarygirl]

Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.

Je déteste aussi la tabulation qui peut causer des erreurs de logique si on ne fait pas attention. Mais c'est ce qui arrive à ceux qui pondent du long code avec des if imbriqués, ce qui n'est pas un bon pattern dans l'absolu. D'ailleurs, je pense que ça m'a ouvert les yeux.
Depuis que je fais du Python, j'ai appris à rédiger des fonctions plus succinctes et mieux modulariser le code.

[HaryRoseAndMac]

La très grande majorité des gens qui ventent Rest comme des fanboys n'ont jamais rien fait de sérieux avec ce langage.

Arrêtez de croire que déjà, ces performances sont au dessus du C ou du C++, car c'est littéralement faux.
Et arrêtez de croire que c'est mieux de coder en Rust qu'en python, car là aussi, c'est faux.

Ce qui intéresse c'est un langage ou il est rapide d'écrire avec et ou ce qui est produit est performant.
Vous pouvez bien prétendre ce que vous voulez, du python pour faire des applications dans le domaine des mathématiques (Machine Learning, ...) ça reste ce qu'il y a de mieux et de loin devant tout le reste.

[wiztricks]

Salut,

Des fois, si. Au fur et à mesure que l'écosystème de Rust progresse, il y a de plus en plus de code Python pour lequel Rust devient une alternative crédible.

Tant mieux si ça crée une compétition qui fait progresser...

En pratique, les développeurs Python, utilisent-ils les annotations de type quand il est pertinent de les utiliser ? Des fois oui, des fois non. Cela dépend qui code. J'ai vu les deux cas.

Pour moi, python restera un langage de scripting à utiliser avec discernement(*). Et je ne vois pas trop l'intérêt des annotations pour ce que j'attends de Python. J'en comprends l'intérêt pour la gestion/contrôle d'un travail d'équipe et le développement plus fiable de gros projets.
Dans la pratique, ce ne sont que des outils de gestion du risque, une assurance qualité... et ça ne fait pas tout (et de loin).

(*)Je parle là des programmeurs professionnels pas d'étudiants à qui on apprend à programmer pour l'intérêt du cheminement programmatique ou les rassurer dans l'utilisation de cet outil dans différents aspects d'un boulot technique.
Que des décideurs embauchent ce genre de profils pour écrire de vrais programmes pas cher (et assez pourris) n'est pas un sujet technique.

- W

[N_BaH]

au-delà de la polémique facile («ce langage général n'est pas adapté aux cas particuliers»), ne s'agit-il pas de faire la promotion de rust* ?

--
* en vogue : le noyau Linux l'intègre, et pourrait, à terme, être totalement réécrit dans ce langage.
?

[wiztricks]

au-delà de la polémique facile («ce langage général n'est pas adapté aux cas particuliers»), ne s'agit-il pas de faire la promotion de rust* ?

Python n'est pas adapté à tout. C'est une réalité technique.

Après on a une réalité économique qui va de trouver des programmeurs qui pourront coder avec le langage X ou Y à combien ils vont coûter en passant par la qualité de ce qu'ils pourront produire.

--

* en vogue : le noyau Linux l'intègre, et pourrait, à terme, être totalement réécrit dans ce langage?

On a le droit de rêver.... mais ré-écrire un code qui marche dans un autre langage parce qu'il est mieux n'a aucun intérêt: çà coute très cher et ça n'apporte pas grand chose côté nouvelles fonctionnalités. Une telle migration prendra des années et d'ici là, peut être que Rust aura été remplacé par un autre langage à la mode.
note: par contre voilà un exemple de ce qu'on ne peut pas coder avec Python.

- W

[defZero]

Phrase d'accroche :

Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon

vs Conclusion :

En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels.

La divergence de la conclusion par rapport à l'énoncé de départ me dérange .

Comparer des langage si différent, ça me fait toujours sourire.
Mais pour rappelle :

1. Python = langage interprété, fortement & dynamique typé (inférence de type à la 1er affectation et pour sa durée de vie).
   Honnêtement, c'est un langage plutôt simple, à la syntaxe constante mais si je devais faire de la performance , j'oublierais l'idée sauf à ce qu'un module coder en natif existe pour ma plateforme cible.
   
2. Rust = langage compilé (AoT), fortement & statiquement typé, avec contrôle des accès mémoire par propriété (pour empêcher/limiter les datas race) et de durée de vie (pour empêcher les débordements/fuite mémoire) à la compilation.
   Avec Rust, le dilemme est plus complexe étant donner qu'il peut ce permettre un panel d'utilisations que les autres langages, compilé nativement, ont rarement avec toutes ses qualités.
   Dans ses possibilité d'abstraction il serait au niveau du Java/C#, mais avec les capacités du C/C++ accoler.
   
3. C, C++ = langage compilé (AoT), faiblement & statiquement typé (proche de la machine quoi).
   Sauf à faire du bas niveau en voulant s'épargner un max d'assembleur pour un minimum de portabilité, je le conseillerais à personne en 2023 au vu des alternatives (manque juste de maturité pour les alternatives, mais elles ont le mérite d'existées).

Si je devais faire un site simple, j'utiliserais PHP (loin d'être le langage le plus élégant/cohérant de l'histoire), mais je pourrais tout à fait le coder en C/C++ pour faire un "cgi".
Le problème est de savoir si c'est pertinent dans mon cas.
En effet qui va payer pour le temp que ça va me prendre pour avoir au final le même résultat, sachant que 99% d'internet n'est pas les GAFAM est n'a pas leurs problématiques de perf, conso, gestion des ressources ?
Et puis si demain je change de poste, bonne chance pour debugger/augmenter des "cgi" en C/C++ bien touffu .

Conclusion, s'il existe autant de langages, c'est bien qu'il existe autant de besoins différents à combler.

[Pyramidev]

C'est l'éternel débat langage compilé/interprété.
Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

Si un développeur a beaucoup de lacunes dans les fondamentaux et qu'on lui demande de coder un programme complexe avec un langage compilé et statiquement typé habituel, alors le code n'aura pas de tests automatisés, il y aura des copiés-collés dans tous les sens et, malgré le typage, les entrées et sorties des opérations ne seront pas claires, car il y aura des variables globales muables (ou d'autres patterns similaires) dans tous les sens. Il y aura aussi plusieurs centaines d'avertissements du compilateur, tous ignorés. Bon, par contre, les paramètres des fonctions seront typés, donc il y aura quand même quelques indices qui traîneront dans tout ce bazar pour la future victime qui reprendra le code plus tard.

Si tu prends le même genre de développeur et que tu lui donnes un langage dynamiquement typé, il te pondras un code qui atteindra des niveaux de catastrophe qu'on ne connaît pas dans le monde des langages statiquement typés. Non seulement il y a encore plus de bogues car il n'y a toujours pas de tests automatisés et car le compilateur ne rattrape plus les erreurs les plus grotesques, mais ce n'est pas tout : quand on lit une fonction quelconque dans le code, on ne sait pas ce qu'elle prend en entrée, on ne sait pas ce qu'elle retourne en sortie et on ne sait même pas toujours quel code est appelé à l'intérieur : objet.methode_dont_le_nom_existe_dans_plein_de_classes(lol). Mais je ne sais pas à quelle(s) classe(s) cet objet peut appartenir !

Les deux exemples précédents, je les ai vus en entreprise.

Avec un mauvais développeur, le code sera mauvais quel que soit le langage. Mais, plus le langage lui permettra d'aller loin dans le mauvais code dès le début de l'apprentissage du langage, plus il ira loin dans l'immaintenabilité.

C, C++ = langage compilé (AoT), faiblement & statiquement typé (proche de la machine quoi).

C++, ce n'est pas le même langage que C. Concernant le typage, on n'est pas du tout au même niveau.

En C, dès qu'on veut faire un peu d'abstraction au runtime, on se retrouve avec des void* qu'il faut convertir de manière un peu sauvage. En outre, en langage C, tout pointeur est nullable, alors que C++ supporte des alternatives aux pointeurs comme les références et std::reference_wrapper.

Sur certains aspects, le C++ est même un peu plus fortement typé que Java. Par exemple, en Java, comme toute classe dérive de Object qui possède une méthode equals, on peut comparer tout objet avec n'importe quel autre objet, même quand ça n'a pas de sens. En C++, par contre, si on écrit objet1 == objet2 sans avoir surchargé l'opérateur == sur le ou les types correspondants, cela provoque une erreur de compilation.

Par contre, pour la gestion de la mémoire, il est vrai que C++ est périlleux si on le compare à Java et Rust.

De toutes façons d'ici la fin de l'année les GitHub CoPilot/GPT5 et autre Google Bard vont certainement être capables de traduire tout langage en un autre et coder eux-mêmes en comprenant nos besoins , spécifications ou même codes (donc un Linux recodé de C à Rust, idem pour Windows depuis son C++, je ne vois pas pourquoi ce serait impossible..?)...

D'ici la fin de l'année ?! En plus, on est déjà en août ! Non, on n'en est pas à ce stade là.

[popo]

Phrase d'accroche :

"Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon"

vs Conclusion :

"En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels."

La divergence de la conclusion par rapport à l'énoncé de départ me dérange .

C'est parce que c'est dérangeant.
l faut lire les articles originaux pour démêler cette traduction approximative.
L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.

[Sve@r]

C'est parce que c'est dérangeant.

Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde

L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.

Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...

[popo]

Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde

Dans mon commentaire "C'est" faisait référence à "La divergence de la conclusion par rapport à l'énoncé de départ".
Ce qui est, effectivement, dérangeant.

Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...

Là aussi, tu n'a pas compris mes propos.
Alors tu les déformes et tu les tournes en ridicule.

Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).

Noter que mon objectif n'était pas d'émettre un avis sur Python (qui soit positif ou négatif).
Mon objectif était d'expliquer pourquoi on a cette divergence de la conclusion par rapport à l'énoncé de départ.

[Sve@r]

Là aussi, tu n'a pas compris mes propos.
Alors tu les déformes et tu les tournes en ridicule.

Pas les tiens, les siens !!! Ce sont les siens que tu as expliqué !!!
Tu me connais non, on a déjà parlé ensemble, je me suis jamais moqué de toi. Un peu d'humour oui sur "dérange/dérangeant" mais bon si ça te... dérange...

Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).

Exactement ce que je dis. Jos Visser a des propos négatifs sur les avions parce que Karun Thankachan encense la choucroute (ou tout autre plat typiquement délicieux que la consonnance de son nom laisse suggérer) et qu'on n'en sert pas dans les avions. Comme quoi

1. j'avais parfaitement compris tes propos
2. c'est toi qui n'a pas compris les miens

[gzii69]

Pour le fait que Rust ne soit pas plus performant que le C++ ?

En tout cas il ne l’est pas moins.
J’ai porté un serveur de comptage que j’avais fait en C++ vers Rust et il avait des perfs du même ordre (plus rapide dans mon cas mais c’est difficile à évaluer sans de nombreux tests et sans doute de petites optimisations des deux côtés).
Et surtout je l’ai modifié pour qu’il soit multi-threads avec connexion par socket en souffrant un peu pour trouver comment faire, mais avec un résultat qui s’est révélé fiable pour la production dès le début.

Pour python, avec les bonnes bibliothèques c’est bien pratique pour mettre en place des chaînes de traitements, avec Pandas ou Polars par exemple on peut faire du traitement de données assez lourd.