Discussion :

[thamn]

Ceci dit, ce n'est certainement pas à l'école que tu apprends à "comprendre les besoins de tes clients", c'est même plutôt l'inverse: tu apprends à faire du joli code commenté qui respecte scrupuleusement des postulats théoriques et des méthodes de gestion de projet idéalistes, tout cela dans un contexte académique et en partant du principe que les clients savent toujours (décrire) ce qu'ils souhaitent et bien entendu, ne changent jamais d'avis. Jamais.

Ben ca, vu le code que je vois je peux te dire qu'il est ni joli ni scrupuleux.
Si je te donne le conseil c'est parce que tu demande, pour ma part j'ai pas de diplome (enfin si j'ai passe 6 mois pour avoir un BTS dans une ecole ou les profs m'on dit que c'etait pas la peine de venir que j'avais qu'a passer le diplome, ce que j'ai fais mais bon je considere pas ca comme un diplome, ou peut etre je considere pas les diplomes en generales peut etre ^^) et j'ai appris par moi meme donc je ne peux qu'etre d'accord avec toi, c'est pas a l'ecole que j'ai appris a apprendre, mais visiblement y'en a qui en on besoin alors pourquoi pas.
Que ton ecole ai invente scala n'a semble t-il pas aider dans l'objectif de te preparer a apprendre du coup? C'est dommage ca sonnait pourtant bien ronflant comme un truc qui coute bien cher

[thamn]

Coder chez soi le dimanche n'est pas si mal, partant du principe que c'est en forgeant qu'on devient forgeron.

Je code chez moi toute la semaine sur mon temps libre si tu veux tout savoir Donc on est pas mal d'accord.
C'est meme comme ca que j'ai appris Rust d'ailleurs et la quasi totalite des langages que je connais..

[Mister Nono]

Comment "bien prendre le temps de former des développeurs en école" si la matière évolue chaque année et "se révolutionne" en moyenne tous les 5 ans ?

Vous pouvez avoir les meilleurs profs du monde et des moyens considérables à disposition, "bien prendre le temps de former" demeure une illusion.

D'ailleurs, ce n'est pas dans les écoles que se forment les développeurs. Il est démontré que les meilleurs d'entre eux sont majoritairement des autodidactes aux capacités d'adaptation hors normes.

L'école, c'est surtout pour avoir des diplômes.

Et non : à l'Université on forme des professionnelles capables de produire un SI de bout en bout avec les phases s'y afférant : analyse, modélisation, approche algorithmique, mathématiques discrètes, compilation...

Et puis on les forme à des concepts du moment comme, par exemple, la data science avec l'approche mathématique qui permet de maîtriser cette discipline : probabilités, intégrales et intégrales secondes, matrices, vectorisations, fonctions exponentielle et logarithme népérien...

Oui, le code peut changer mais pas les mécanismes permettant d'appréhender la discipline : donc la formation est solide.

Là se trouve une grande différence avec un codeur, souvent formé en quelques semaines, sur un langage qui changera quelques années plus tard et qui deviendra obsolète.

Un codeur, aussi bon soit-il ne pourra pas remplacer un Ingénieur ou du Docteur ayant de nombreuses années de formations Universitaires.

A+

[Invité]

Un codeur, aussi bon soit-il ne pourra pas remplacer un Ingénieur ou du Docteur ayant de nombreuses années de formations Universitaires.

A+

Et pourtant des gamins qui ne sont même pas encore au lycée parviennent à mettre en défaut des infrastructures, systèmes et logiciels "si savamment" conçus par les personnes dont vous parlez.

Soyez humble.

[Mister Nono]

Et pourtant des gamins qui ne sont même pas encore au lycée parviennent à mettre en défaut des infrastructures, systèmes et logiciels "si savamment" conçus par les personnes dont vous parlez.

Soyez humble.

Ce n'est pas un problème d'humilité ou non. Il s'agit d'une réalité, ni plus, ni moins.

Maintenant il y a des personnes qui sont des génies. Mais le fait d'en trouver une poignée ne constitue pas une vérité pour tous.

Comme en data science : quand des données sortent du domaine on parle de outliers. On les retire même des jeux de données pour ne pas "biaiser" les résultats.

Alors évitons de "biaiser" les conclusions et de dire tout et n'importe quoi.

[dlandelle]

Cette proposition n'est pas crédible de la part de la firme de Redmond dont les architectures sont les plus merdiques et les moins sécurisées.
Un grand mythomane qui fait aussi dans les vaccins qui tuent et l'identité numérique devrait inspirer méfiance.

Faire la promotion d'un langage natif quand on code tout un OS sur une VM et qu'on le répand dans son cloud dans le monde entier, c'est se foutre du monde en terme de consommation.

En terme de sécurité, ounidoze a toujours été une passoire, avec des failles de sécurité intentionnelles car les langages qui sont proposés en back office violent tous les principes de programmation.
(déclarations implicites, conversion implicites, langages interprétés, grammaires non LLK, manque d'orthogonalité, etc.). On peut parler de VB et de Powershell. Les autres langages de visual studio génèrent tous le même pseudo-code, ça coute moins cher à développer, et c'est pas plus mal pour les interfaces et le debug, soit.

Au début de .NET Micro$oft a même émulé des fonctions natives de l'API WIN32 en .NET : c'est presque aussi con que la voiture électrique (pour qui a des bases en thermodynamique).

L'OS lui-même camoufle ses défaillances nombreuses dans la VM qui sécurise sa propre excécution : n'est-il pas drôle d'avoir un OS tellement fiable qu'il faille lui laisser en permanence un filet en dessous ?

Quand des applications Micro$oft plantent, elle redémarrent silencieusement, comme si rien ne s'était passé, quelle classe ;-)

On peut aussi se gausser de "Arrêter" qui ne fait qu'un veille prolongée pour camoufler le temps de démarrage et d'arrêt lamentable de cet OS.

Ajoutons à cela des mises à jour incessantes, et des vrais redémarrages qui prennent un temps considérables (quand ça redémarre).

Je me rappelle d'un déménagement avec une SUN sous SOLARIS, la machine n'avait pas rebooté depuis 4 ans.

Comparer ouindoze à linux en terme de sécurité est juste drôle, même si malheureusement Linux a été infecté par de nombreuses taupes de Micro$oft ou Oracle (pas pauvais non plus, ils arrivent à imposer des rustines dans le noyau Linux pour compenser les merdes dans Java : une honte absolue qui mérite le terme de sabotage.).

Alors Rust ? c'est bien simple je n'ai même pas envie de perdre mon temps à regarder.

[zecreator]

Il ne s'agit pas de savoir si tel ou tel langage est mieux ou pas. Rust a sans doute de grandes qualités, tout comme les autres langages. Le problème n'est absolument pas là.
C'est juste que dans l'offre des langages proposée aujourd'hui, aucun d'entre eux ne crée de vraie vocation. Pour la simple raison que la majorité des langages ne sont pas du tout simples à appréhender pour quelqu'un qui n'a jamais codé de sa vie.

De l'école au lycée, les étudiants passent de Scratch à Python. C'est le grand écart. Tu m'étonnes que sortis du parcours scolaire les gamins n'est absolument pas l'envie de coder. Et pourtant, dans un avenir proche, pour trouver du boulot ils devront avoir un minimum de connaissance en programmation, ça va être très chaud pour eux.

Pour nous, développeurs depuis plusieurs années, cela nous parait évident. Un petit script python d'installation, un petit "apt-get", une installation de dépendance... C'est pas le bout du Monde. On a tellement pas eu le choix de faire comme ça, que cela nous semble la manière normale de bosser. Et on ne se pose même plus de question.

Et si tu n'es pas anglophone, bon courage pour comprendre les tutos.

[AoCannaille]

C'est juste que dans l'offre des langages proposée aujourd'hui, aucun d'entre eux ne crée de vraie vocation

Les langages sont des outils pour faire quelque chose. Je n'ai jamais entendu dire un ébéniste "Cette scie circulaire m'a créée une vocation". Non, la vocation, c'est de faire des meubles beaux/pratiques/durables en fonction du contexte.

C'est pareil pour le logiciel, on veut faire des logiciels beaux/utiles/durables en fonction du contexte.

être passionné par un langage, c'est comme être passionné par un tournevis, c'est absurde, et c'est se limiter inutilement le champs des possibles.

Et surtout, pour boucler la métaphore filée, c'est se diriger tout droit sur le fameux adage : "Quand le seul outils qu'on maitrise c'est un marteau, alors tous les problèmes ressemblent à des clous".

Et si tu n'es pas anglophone, bon courage pour comprendre les tutos.

Je connais une communauté géniale avec un corpus de tutoriel francophone incroyable, je te conseille d'y faire un tour : https://www.developpez.net

[zecreator]

Les langages sont des outils pour faire quelque chose. Je n'ai jamais entendu dire un ébéniste "Cette scie circulaire m'a créée une vocation". Non, la vocation, c'est de faire des meubles beaux/pratiques/durables en fonction du contexte.

C'est pareil pour le logiciel, on veut faire des logiciels beaux/utiles/durables en fonction du contexte.

être passionné par un langage, c'est comme être passionné par un tournevis, c'est absurde, et c'est se limiter inutilement le champs des possibles.

Quand je parle de "créer de la vocation", ce n'est pas uniquement par le langage, mais aussi par la facilité d'accéder à ce langage, de l'apprendre et de ne pas se taper la tête contre les murs avant d'afficher quelque chose à l'écran. Pour moi, c'est la découverte du langage BASIC, sur Thomson à l'époque du "Plan informatique pour tous". J'ai compris le potentiel créatif de l'ordinateur et c'est devenue une vraie passion. Et toute une génération de développeurs passionnés comme moi a émergée avec ce langage.

Cela ne m'empêche pas d'être un virtuose polyglotte de la programmation.

L'apprentissage par la souffrance n'apprend rien et ne donne pas envie.

[tralloc]

Quand je parle de "créer de la vocation", ce n'est pas uniquement par le langage, mais aussi par la facilité d'accéder à ce langage, de l'apprendre et de ne pas se taper la tête contre les murs avant d'afficher quelque chose à l'écran. Pour moi, c'est la découverte du langage BASIC, sur Thomson à l'époque du "Plan informatique pour tous". J'ai compris le potentiel créatif de l'ordinateur et c'est devenue une vraie passion. Et toute une génération de développeurs passionnés comme moi a émergée avec ce langage.

Cela ne m'empêche pas d'être un virtuose polyglotte de la programmation.

L'apprentissage par la souffrance n'apprend rien et ne donne pas envie.

Voici mon humble avis:
il me semble que python peut créer comme tu dis "de la vocation", c'est un langage simple au départ, qui permet d'avoir une console bien pratique pour comprendre les premières notions. Qu'est-ce qu'une variable, un objet en mémoire...
Ensuite tu peux écrire tes premiers scripts faisant plus facilement que d'autres langages des opérations simples ou un peu plus évoluées en te concentrant sur l’algorithme et non la technique
C'est un langage très ouvert et très transparent. par exemple tu peux savoir en une commande quelles sont les attributs ou méthodes d'un objet, sa taille en mémoire, son type...
Puis tu peux découvrir la modélisation objet, puis d'autres subtilités.
C'est un langage qui comprend une bonne communauté et de ce fait de nombreux tutos en français. Une partie de la doc est disponible en français aussi.
C'est un couteau suisse qui te permet de faire des scripts, des serveurs web de manière synchrone ou asynchrone, du calcul scientifique et certainement bien d'autres choses.
Malheureusement le compilateur est lent donc tu es quand même limité si tu ne veux pas bouffer trop d'énergie.

Heureusement que Guido van Rossum a annoncé pouvoir diviser par 5 le temps d'exécution. Cela ne va pas tout faire... mais c'est déjà ça, ce n'est peut-être qu'un début ???

Alors après avoir compris ce langage tu peux te tourner vers d'autres, plus complexes à appréhender techniquement, mais plus efficaces dans l'exécution... et ta vocation peut se poursuivre.

[thamn]

Et si tu n'es pas anglophone, bon courage pour comprendre les tutos.

Ouai y'a un moment aussi tu vas devoir coder et la plupart des langages ressemble a l'anglais alors bon c'est peut-etre un des premier truc a apprendre peut-etre?

[Pixoo]

Les résultats du Pascal sont surprenants

[der§en]

Je suis très très très septique quand au sérieux de cette étude, en y voyant que selon eux, java est moins énergivore que le langage Pascal !

[Bruno]

Pourquoi l'utilisation du langage de programmation Python serait en train de « détruire la planète »,
d'après Mohammed Ayar

Dans une étude intitulée : Efficacité énergétique dans les différents langages de programmation et publiée en 2019, six chercheurs de trois universités ont révélé que Perl, Python et Ruby sont les langages de programmations les plus voraces en énergie. Python a des résultats médiocres en termes de puissance et de temps d'exécution, et est même moins performant que Lua et Perl en termes de puissance. Pourquoi le problème c'est Python et pas Perl ou LUA ? Parce que c'est le plus utilisé.

Alors que les uns se plaignent d’une possible destruction de notre planète du fait des différentes technologies en place aujourd’hui, les autres pensent au contraire que la technologie peut résoudre les problèmes environnementaux. Dans une étude intitulée : Efficacité énergétique dans les différents langages de programmation et publiée en 2019, six chercheurs de trois universités portugaises ont révélé que Perl, Python et Ruby sont les langages de programmations les plus voraces en énergie. Pour comparer correctement l'efficacité énergétique entre différents langages, il faut obtenir des implémentations comparables de solutions à un ensemble représentatif de problèmes. Et c’est ce qui avait été fait par les chercheurs des universités portugaises.

« Malgré les inconvénients de Python, j'ai toujours été convaincu que la proposition de valeur de Python - lisibilité, maintenabilité, communauté - peut difficilement être surpassée. Cependant, au fur et à mesure que je m'enfonce dans le terrier du lapin, de nouveaux inconvénients cachés ont commencé à faire surface. Des inconvénients sur lesquels je ne pouvais plus fermer les yeux. L'un de ces inconvénients est la durabilité », écrit Mohammed Ayar.

Avec l'adoption croissante des appareils sans fil, il est plus que jamais temps de coder en tenant compte de la consommation d'énergie. Les téléphones mobiles, les ordinateurs, les tablettes et les gadgets technologiques sont alimentés en électricité et consomment de l'énergie. Intégrées à ces appareils, les applications déterminent la consommation d'énergie, et les logiciels qui consomment moins d'énergie sont dits « économes en énergie ». Lorsqu’un téléphone surchauffe, c'est parce que vous utilisez une certaine application. La chaleur excessive, à son tour, vide votre batterie, ce qui vous oblige à charger votre téléphone. Plus vous chargez votre téléphone, plus il consomme d'énergie. De même, moins vous chargez votre téléphone, mieux c'est - pour votre batterie et pour l'environnement.

Il y a une question qui démange tout programmeur soucieux de l'énergie. Cette question est la suivante : un programme plus rapide est-il, de par sa conception, économe en énergie ? Les réponses à cette question sont assez diverses. Certains disent qu'un programme plus rapide a tendance à être économe en énergie parce qu'il se ferme plus tôt. D'autres adoptent une approche mathématique et suggèrent que ce n'est pas toujours le cas :

E (Energy) = P (Power) x T(Time)

La comparaison des performances des logiciels est une tâche suffisamment complexe. Les logiciels peuvent être développés à l'aide de différents langages de programmation et de différents frameworks. De même, différents algorithmes peuvent produire le même logiciel. Les langages de programmation ont historiquement été la métrique par défaut dans l'espace énergétique. Mais là encore, il est possible de rendre un langage de programmation plus efficace qu'un autre en optimisant le compilateur/interprète, en améliorant les frameworks/librairies.

La consommation d'énergie aurait été difficile à calculer s’il nexistait pas des techniques établies (par exemple, le RAPL d'Intel, Running Average Power Limit Energy Reporting, Qualcomm TrepN...) qui produisent des mesures de consommation d'énergie assez précises. Cependant, il y a un avertissement. RAPL n'est supporté que par les chipsets d'Intel. Par conséquent, si vous n'utilisez pas un processeur Intel et que vous souhaitez effectuer ces tests sur votre machine locale, il est possible d’explorer d'autres interfaces de rapport de consommation d'énergie (par exemple, le Trepn Power Profiler de Qualcomm).

Cela dit, pour embellir RAPL en Python, nous pouvons utiliser la bibliothèque pyRAPL. Java dispose de JRAPL et C de RAPL. Le script Python ressemble à quelque chose comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
import pyRAPL

pyRAPL.setup() 

@pyRAPL.measure
def doSomething():
# Instructions to be evaluated.

doSomething()

Temps

Afin de mesurer le temps, Mohammed Ayar utilise un script simple qui permet de mesurer le temps d'exécution d'un programme. Il existe différents moyens d'y parvenir, voici un script simple qui le fait à partir de références :

Code :

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

1
2
3
4
5
6
7
8
9
from time import time...
while (i < N):
   start = time()
   ...
   # insert program here
   ...
   end = time()
   ...# Calculate average taken time
...

Selon Mohammed Ayar, il est difficile d'obtenir directement la puissance car son unité (W) est plutôt un quantificateur théorique. Par conséquent, en suivant l'école de pensée qui stipule que l'énergie dissipée (J) = Temps (S) x Puissance (W), il est possible de calculer facilement la puissance consommée par chaque langage de programmation.

La dernière pièce du puzzle consiste à choisir un programme mis en œuvre de manière similaire dans différents langages de programmation. L'idée est que choisir un programme optimisé dans un langage et algorithmiquement déficient dans d'autres rendrait la comparaison biaisée, tuant la robustesse de l'expérience. Pour éviter ce problème, Mohammed Ayar emprunte les problèmes de référence proposés dans The Computer Language Benchmark Game (CLBG).

CLBG est une initiative open source pour aider à mesurer les performances de différents langages de programmation. Il propose un ensemble de problèmes informatisés optimisés pour différents langages de programmation afin de garantir une comparaison précise des performances. Tous les éléments réunis, le calcul de l'énergie (E), du temps (ms) et de la puissance (W) conduit aux chiffres suivants :

Comme nous pouvons le constater, Python se trouve malheureusement en bas du classement. Il a des résultats médiocres en termes de puissance et de temps d'exécution. En fait, Python est même moins performant que Lua et Perl en termes de puissance. Il se trouve qu'ils sont nettement plus lents. D'où leur forte consommation d'énergie. En réduisant les langages de programmation aux langages interprétés, nous intégrons les chiffres ci-dessus dans un graphique pour les rendre plus expressifs.

À la lecture de cette figure, nous remarquons que Python est le troisième langage le plus mauvais en termes de consommation d'énergie du CPU, précédé par Lua et Perl. En revanche, le C domine les langages de programmation en termes de consommation d'énergie, ce qui en fait un pari intéressant pour les logiciels verts.
Les deuxième et troisième places reviennent respectivement au C++ et à Rust, ce qui confirme l'engouement massif pour Rust dans la communauté logicielle. La principale mesure sur laquelle Mohammed Ayar c’est appuyé dans cette analyse pour représenter la durabilité est la consommation d'énergie (E).

L'énergie est une forme de chaleur qui se manifeste lorsqu'un courant électrique traverse une résistance. « Ayant une formation d'ingénieur en électricité, je trouve que l'énergie (E) en joules est le meilleur candidat pour représenter la durabilité, car c'est un sous-produit des déchets solides », écrit Mohammed Ayar.

Cela dit, on aurait pu mettre « Perl détruit la planète » ou « Lua détruit la planète » en titre, car leur consommation d'énergie est plus élevée que celle de Python. Cependant, aucun des deux n'est utilisé autant que Python. Python est très utilisé dans l'industrie, en particulier dans l'intelligence artificielle et l'apprentissage automatique. En fait, les géants de la technologie, dont Google et Meta, font pression pour l'utilisation de Python.

Toutefois, Mohammed Ayar note que Python n'est pas un langage de programmation écologique en soi. Son empreinte énergétique est en moyenne 40 fois supérieure à celle du C, du C++ et du Rust. Le C et le C++ seraient naturellement difficiles à utiliser pour certains. Lors d’une conférence d’AWS tenue l’année dernière, Shane Miller, présidente de la Fondation Rust, et Carl Lerche, chef de projet de Tokio, ont plaidé en faveur de l'utilisation de Rust pour minimiser l'impact environnemental, tout en précisant que sa courbe d'apprentissage abrupte rendait la tâche difficile.

Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research, avec la contribution du créateur de JavaScript Brendan Eich. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités fondamentales du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

Rust fait partie des langages de programmation les plus efficaces. La source citée pour cela est l’article susmentionné, de 2017, qui a mesuré les performances, l'utilisation de la mémoire et l'efficacité énergétique de 27 langages de programmation, et a placé C comme le plus efficace, mais Rust juste derrière avec seulement trois pour cent de plus d'utilisation d'énergie. Java utilise près du double d'énergie, C# plus de trois fois, et Python plus de 75 fois, selon l'étude.

Source : Mohammed Ayar's blog

Et vous ?

Pensez-vous que l'analyse de Mohammed Ayar est pertinente ou pas, et pourquoi ?

Selon vous, un programme plus rapide est-il, de par sa conception, économe en énergie ?

Rust deviendra-t-il le principal concurrent du langage C et du C++ dans le domaine des "langages de programmation plus écologiques" ?

Voir aussi :

Rust peut-il sauver la planète ? Un composant JavaScript a été réécrit en Rust et aurait une amélioration de 50 % de la latence, une réduction de 75 % de l'utilisation du CPU et 95 % de la mémoire

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

[earhater]

Lorsqu’un téléphone surchauffe, c'est parce que vous utilisez une certaine application. La chaleur excessive, à son tour, vide votre batterie, ce qui vous oblige à charger votre téléphone. Plus vous chargez votre téléphone, plus il consomme d'énergie. De même, moins vous chargez votre téléphone, mieux c'est - pour votre batterie et pour l'environnement.

Quand on sait que 90% du bilan carbonne d'un smartphone se situe dans sa fabrication, transport et recyclage (ou déchetterie) on peut quand même se dire qu'améliorer le bilan CO2 de l'utilisation d'un smartphone reste une optimisation à la marge. Je préfère un smartphone que je dois recharger 3 fois par jours (ignorons l'inconfort de la chose) mais durable (ex fairphone) qu'un smartphone à la mode Chinoise (huawei, xiaomi, ...) qui n'ont aucun support de l'OS après 2 ans et sont trop difficile à réparer (c'est vraiment des produits de conso) si on s'en tient à l'impact environmental.

C'est dommage de faire la majorité de l'article là dessus (de la part des chercheurs) car cela me semble contre productif alors qu'il y a de réel gains à ne pas utiliser python pour d'autres cas d'usage, je pense notemment aux API : faire du backend en python va requérir plus d'instances en cas de volumétrie par rapport à des langages compilés bad niveau (rust, go, c, ...) et là le gain est plus important.

[Fagus]

Pensez-vous que l'analyse de Mohammed Ayar est pertinente ou pas, et pourquoi ?

Bof. 90% de l'énergie consommée par les appareils informatiques vient de leur fabrication (extraction de minerais, etc.).
Réduire de 10% le renouvellement du parc ça a quasi 2x plus d'impact que de réduire de 50% la consommation d'électricité du parc (d'autant que ce dernier objectif ne serait pas atteint juste en remplaçant tout le python par du c)

Python c'est de la colle. Si son code python consomme trop de CPU, peut être qu'il est temps de déléguer à un module compilé ou d'écrire ce dernier.

[smarties]

Avant d'accuser Python, il faudrait agir en amont :
- garder le plus longtemps ses ressources informatique et ne pas renouveler tant que ça ne tombe pas en panne (et on peut généralement réparer)
- mutualiser les ressources, tous les serveurs ne demandent pas 100% de puissance ou de RAM tout le temps !

Python est certes pas très rapide mais il est adossé à plusieurs bibliothèques natives aussi ! Donc quand le programme Python ne fait pas de calcul, il ne doit pas avoir une forte emprunte énergétique.
Dans le milieu scientifique, quelle est l'emprunte de Matlab et de Scilab ?

[yahiko]

Programmer en Python apparaît donc comme étant peu responsable ce qui ne m'étonne qu'à moitié au vue de ses performances intrinsèques sommes toutes très médiocres.
Pour rester dans la famille des langages interprétés avec une courbe d'apprentissage abordable, je note que JavaScript / TypeScript est sans doute la meilleure alternative au langage reptile.

[Pyramidev]

En France, trouver un poste en Rust, c'est quasiment mission impossible.

De ce que j'ai vu pendant des entretiens d'embauche l'an dernier, dans les entreprises où le backend est fait en Python, quand les développeurs décident de migrer un morceau pour améliorer les performances, on dirait que c'est le langage Go qui est le plus souvent choisi.

[GATEN]

Python est un genre de serpents de la famille des Pythonidae.