Semaphore : de nombreux nouveaux projets commerciaux sont développés dans des langages qui ne sont plus supportés
Quelles en sont les raisons ?

Le , par Michael Guilloux, Chroniqueur Actualités
À quel moment passez-vous à une nouvelle version d'un langage ?
Semaphore CI est un fournisseur de solutions de Continous Integration & Delivery. Il est également connu pour ses publications régulières sur les versions de langages open source qui sont utilisées dans des projets commerciaux. Pour l’année 2017, Semaphore CI vient de publier une compilation de différents rapports qui montrent quelles versions des langages open source populaires comme Java, Go, Node.js, PHP, Python et Ruby sont utilisées dans les projets commerciaux, nouveaux ou existants. Les données sont basées sur des milliers de projets privés qui sont testés et déployés sur Semaphore.

Le constat est que parmi ces projets commerciaux, nombreux sont développés dans des versions de langage qui ne sont plus prises en charge. La réalité diffère toutefois d’un langage à l’autre. Quel est le donc le constat pour chacun de ces langages et qu’est-ce qui pourrait expliquer cela ?

Java

Java 7 qui n’est plus supporté est encore utilisé par 17 % dans des projets commerciaux Java. La plupart des projets Java sont toutefois basés sur Java 8, ce qui est une bonne nouvelle puisque cette version est encore supportée. Par contre, Java 9 a été publié en septembre 2017, mais il semble qu'il ne verra aucune adoption significative parmi les projets existants. Oracle a annoncé que Java 8 sera une version LTS supportée jusqu'en 2022, tandis que Java 9 ne va pas bénéficier d'un support à long terme. Ceci, avec la nouvelle fonctionnalité de modularité qui demande un certain temps pour s'y habituer, est probablement ce qui pousse la plupart des équipes à attendre la prochaine version à long terme, Java 18.9 LTS qui devrait arriver en septembre 2018.


Node.js

Beaucoup de choses sont arrivées au runtime Node.js ces dernières années. Après avoir eu une adoption précoce, il a vu sa croissance ralentie, été forké, avant d'arriver enfin à une consolidation avec un nouveau calendrier de diffusion. En conséquence, la réalité est que près d'un tiers de tous les projets sont basés sur une version obsolète de Node, alors que moins de 10 % utilisent une version publiée en 2017 (v8 ou v9). Node 9 a été publié cet automne, mais Semaphore ne note pas encore d'adoption significative. Il est ici important de noter que c'est seulement depuis le mois de mars qu'AWS Lambda prend en charge la version 6.10 de Node.js alors que la version 0.10 de Node.js a été dépréciée fin avril. Cela peut-il expliquer en partie l'utilisation de versions Node.js non prises en charge dans les projets commerciaux.


PHP

PHP figure parmi les dix premiers langages les plus utilisés depuis des années, et il est présent côté serveur pour la majorité des sites accessibles aujourd'hui. La plupart des projets PHP (37 %) utilisent cependant la version 5.6, dont la période de support actif s'est terminée le 19 janvier 2017. Cette version continuera à recevoir des mises à jour de sécurité jusqu'à la fin de 2018. Les versions 5.3, 5.4 et 5.5, qui ne sont plus supportées, sont également utilisées dans 34 % des projets PHP. D'après Semaphore CI, cela peut être dû au fait que le processus de mise à jour de 5.x à 7.x est complexe. Par exemple, de nombreuses erreurs fatales ont été converties en exceptions, il y a beaucoup de changements dans la gestion des variables et des entiers, etc.

La version 7.0 est utilisée dans 19 % de tous les projets PHP. Cette version a été publiée en décembre 2015, et sa période de support actif a également pris fin depuis le 3 décembre. Quant à la version 7.1 qui a été publiée en décembre 2016, jusqu'à présent seulement 9 % des projets PHP l'utilisent. PHP 7.2 ne figure pas encore dans les statistiques de Semaphore, ce qui est normal puisque cette version a été publiée il y a un mois seulement.



Python

Malgré la sortie de Python 3 en 2008, plus de 70 % des projets commerciaux étaient encore basés sur la version 2.7 l'année dernière. Cette année, les résultats sont un peu meilleurs pour Python 3, mais pas beaucoup. Il faut noter que le support de Python 2.7 est encore maintenu de manière exceptionnelle jusqu'en 2020, en raison des difficultés de migrer de la branche 2.x vers Python 3.x. Il y a aussi le support de Python 2.7 par des fournisseurs. C'est le cas par exemple d'AWS Lambda qui prend en charge Python 3.6 et 2.7 depuis le mois d'avril.


Ruby

Il faut noter ici que plus de 85 % des projets Ruby utilisent la version 2.0 ou une version supérieure. D'après Semaphore, dans l'ensemble, il semble que dès que les équipes passent de 1.9.3 à 2.x, il devient plus facile de passer à des versions plus récentes.

Une chose importante à noter est que les versions 2.0 et 2.1 ont atteint leur fin de vie, ce qui fait que 33 % des projets Ruby utilisent des versions qui ne sont plus supportées. En outre, la fin de vie de Ruby 2.2 (utilisée dans 31,8 % des projets) est prévue pour le 31 mars 2018. Il est donc fortement recommandé de passer à des versions plus récentes, car les anciennes versions ne reçoivent aucune mise à jour de sécurité. Une autre chose que fait remarquer Semaphore ici est que Rails 5 ne supporte que Ruby 2.2.2 et les versions supérieures. Cela pourrait encore une fois indiquer que l'utilisation d'une version d'un langage dans les projets est en quelque sorte influencée par le support offert par les fournisseurs de technologie utilisant ce langage.


Go

La politique de publication de Go stipule que chaque version majeure de Go est supportée jusqu'à ce qu'il y ait deux nouvelles versions majeures. Ainsi, le graphique suivant montre que 60 % des projets Go commerciaux utilisent actuellement une version officiellement prise en charge (Go 1.7, 1.8 et 1.9).



Source : Semaphore

Et vous ?

Que pensez-vous de ces statistiques ?
Quand décidez-vous de passer à une version plus récente d'un langage ?
Avez-vous encore des projets développés dans des langages qui ne sont plus supportés ?
Si oui, de quels langages s'agit-il et pour quelles raisons ?

Voir aussi :

En 2017, Python 2.7 est plus utilisé (63,7 %) que la version 3.x dans les projets commerciaux, selon Semaphore CI


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de marc.collin marc.collin - Membre éclairé https://www.developpez.com
le 28/12/2017 à 16:56
Ces stats reflètent pas mal ce que j'ai plus voir depuis quelques années

Habituellement je teste la version la plus récente du langage assez tôt, cependant avant de l'utiliser dans un projet, je m'assure que la version du langage est bien supporté par les libraries, framework que j'utiliserais ainsi que l'environnement de développement.

J'utilise encore java 8, car il y a encore trop de problème avec java 9 concernant spring, netbeans, spring boot...
Avatar de 23JFK 23JFK - Membre expérimenté https://www.developpez.com
le 28/12/2017 à 18:34
Pourquoi ? D'une part par le manque de maîtrise pour le programmeur qui doit se taper la p'tite doc de 1000 pages (C++ toise les 1600 pages) en anglais qui accompagne chaque révision (les traductions arrivant une à deux années après... quand elles arrivent), Et d'autre part l’absence de recule quant à la fiabilité du nouveau bordel (c'est pas comme si l'industrie IT n'avait jamais connu de gros foirages lors de release/beta).
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 29/12/2017 à 10:13
Je suis assez en phase avec @marc.collin
Ce n'est pas parce qu'une nouvelle release du langage sort que l'ensemble de l'écosystème suit immédiatement (IDE, serveurs d'applications, frameworks, api, librairies, analyseurs de code, etc.).
Faut attendre quelques semaines / mois pour que l'ensemble de l'écosystème de dev et d'exécution se mettent à niveau et se stabilisent.

De plus, c'est vrai dans l'IT mais pas uniquement, il ne faut jamais se jeter immédiatement sur les nouveautés car y a forcément quelques bugs qui sont passés à la trappe lors des contrôles qualités (et rarement des petites choses).
On peut être sûr qu'on va avoir au moins 1 à 5 patchs correctifs dans les 2 mois qui suivent la publication de la nouvelle release.
Alors autant attendre un peu que ça se stabilise un peu.

Pour finir, comme l'a très bien dit @23JFK, faut aussi que les développeurs se forment ou soient formés (pour les chanceux dont l'entreprise payent des formations).
De même que les organismes de formations aient le temps de se mettre à jour...
Ainsi que les éditeurs qui publient des livrent sur le sujet pour compléter / expliciter les releases notes officielles parfois obscures.
Avatar de koyosama koyosama - Membre éprouvé https://www.developpez.com
le 30/12/2017 à 15:13
Citation Envoyé par Saverok Voir le message

De plus, c'est vrai dans l'IT mais pas uniquement, il ne faut jamais se jeter immédiatement sur les nouveautés car y a forcément quelques bugs qui sont passés à la trappe lors des contrôles qualités (et rarement des petites choses).
On peut être sûr qu'on va avoir au moins 1 à 5 patchs correctifs dans les 2 mois qui suivent la publication de la nouvelle release.
Alors autant attendre un peu que ça se stabilise un peu.
Tu peux eviter cela en testant sur des nouvelles environnement si tu as fais le découpage de ton application et suivant les principes de développement modernes (je dirais ricains car ils sont pas vraiment moderne). C'est l'avantage du container, changer de langage à la volée ou revenir en arrière sur tel environnement.

Et si le projet est bien fait, tu dois avoir 4 niveaux de tests : test unitaires, test d'acceptance, test de performance et test de bout en bout. Et cela devrait couvrir les 70% de facteurs que tu as.
Sans compter qu'avec un approache 12factors, changer de language c'est comme changer de chaussette. Bien sûre Java 9 a tout pété, mais tu peux t'appuyer sur tests unitaires pour faire la modification aussitôts. Même grahique cela a un impact minim. J'ai vu des équipe qui sont passé de telles languages à telles langauges sur dexu ans car ils ont découpé correctement leur coder.

Si tu as fais cela, cela devrait enlever pas mal d'effort et un meilleur isolation, et tu peux contenir tes erreurs. Regarde comment les développeur wordpress font, c'est pas parfait c'est 40% de la perfection mais quand tu as un module ou thème qui merde, tu changes le module ou le thème.

Même des connections spécifique pour un système d'exploitation, tu ne devrais pas avoir ce problème.
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 02/01/2018 à 10:46
Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

La confusion est facile à faire en cette époque où même les créateurs font tout pour brouiller les cartes, mais la distinction est primordiale. L'écrasante majorité des versions de langage sont rétro compatibles. On casse rarement du code parce qu'on met à jour un runtime qui introduit une nouvelle version d'un langage. Au pire, des fonctions des bibliothèques de base (ou de bibliothèques tierces qu'on est obligé de mettre à jour) sont deprecated. On peut bénéficier de nouvelles primitives du langage qui sont introduites, mais on n'est jamais obligé de tout changer.

Langage
Bibliothèque
Framework
Runtime
Plateforme

Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.

PS : Node.js n'est pas un langage
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 02/01/2018 à 13:19
Citation Envoyé par koyosama Voir le message
Tu peux eviter cela en testant sur des nouvelles environnement si tu as fais le découpage de ton application et suivant les principes de développement modernes (je dirais ricains car ils sont pas vraiment moderne). C'est l'avantage du container, changer de langage à la volée ou revenir en arrière sur tel environnement.

Et si le projet est bien fait, tu dois avoir 4 niveaux de tests : test unitaires, test d'acceptance, test de performance et test de bout en bout. Et cela devrait couvrir les 70% de facteurs que tu as.
Sans compter qu'avec un approache 12factors, changer de language c'est comme changer de chaussette. Bien sûre Java 9 a tout pété, mais tu peux t'appuyer sur tests unitaires pour faire la modification aussitôts. Même grahique cela a un impact minim. J'ai vu des équipe qui sont passé de telles languages à telles langauges sur dexu ans car ils ont découpé correctement leur coder.
Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.

Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.

Je viens tout juste de récupérer une application en plus à mon périmètre et je déprime sévère car il n'y a que 2 env. : la recette et la prod.
Les développeurs travaillent en local mais connectés à la BDD de recette
Mieux encore, il n'y a aucun flux qui tournent en recette donc on est obligé de faire un dump de prod vers la recette pour actualiser la BDD et conserver un jeu de données cohérents en recette...
La misère totale.
Des env. de travail pourri, j'en ai connu quelques uns mais là, on a franchi un nouveau palier.
Le pire, c'est que je ne suis même pas dans une petite PME mais au sein d'un grand compte et que les autres applications dont j'ai la charge sont tout de même mieux lotis.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 02/01/2018 à 15:56
Citation Envoyé par Saverok  Voir le message
Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.

Et du ministère qui demande des délais délirants à nos clients, qui nous le répercutent, bien obligés. Et on se fait tancer par le grand chef américain parce-qu'on a pas respecté la procédure. Ben oui, si on prend le temps de la respecter, le client doit payer des centaines de milliers d'euros de pénalités au ministère. Et nous le répercute ensuite.

Citation Envoyé par Saverok  Voir le message
Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.

Sans compter les résistants, hostiles à toute forme de structuration du travail, parce qu'ils ont peur d'être fliqués(à tort ou à raison, suivant les cas)

Citation Envoyé par Saverok  Voir le message
Je viens tout juste de récupérer une application en plus à mon périmètre et je déprime sévère car il n'y a que 2 env. : la recette et la prod.

Les développeurs travaillent en local mais connectés à la BDD de recette [/QUOTE]

Oh, chochotte, tu ne fais même pas les tests en prod, et tu te plains? - bon, honnêtement, ça ne m'est pas arrivé souvent. Mais ça m'est arrivé.

Citation Envoyé par Saverok  Voir le message
Mieux encore, il n'y a aucun flux qui tournent en recette donc on est obligé de faire un dump de prod vers la recette pour actualiser la BDD et conserver un jeu de données cohérents en recette...
La misère totale.

Oui, ça, c'est la misère. Après, ça dépend de l'appli. En hospitalier, il y a très peu de batches, et le peu qu'il y a peut être lancés au besoin depuis l'interface, donc ça ne me manque pas, ici. En bancaire, par contre, c'était la catastrophe.
Avatar de clementmarcotte clementmarcotte - Expert éminent https://www.developpez.com
le 02/01/2018 à 23:54
Cela me rappelle l'historique "Bogue de l'an 2000", avec un tas de vieux programmes en COBOL fonctionnant avec des années codées sur deux chiffres, créés par des programmeurs qui voulaient sauver de l'espace mémoire rare et précieux. Les vieux programmes ont dû être corrigés dans l'urgence. Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées

Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.

P.S. Là, j'ai mis le lien vers Radio-Canada, mais n'importe lequel média canadien (francophone ou anglophone) doit avoir son lot d'histoires d'horreurs de fonctionnaires avec pas de paye depuis une éternité ou des erreurs paye après paye.
Avatar de wolinn wolinn - Membre éclairé https://www.developpez.com
le 03/01/2018 à 11:06
Pour le C++, je passerai directement du C++ 11 au 17, sans avoir installé de compilateur pour la version intermédiaire 14, dont les apports étaient assez mineurs.
Par ailleurs, j'ai encore du code en C++ 98, qui a donc 20 ans, mais je ne réécris que lorsque cela apporte vraiment quelque chose au niveau des performances.
=> j'apprécie bien un langage préservant la compatibilité sur 15, 20 ans, et plus, j'ai autre chose à faire qu'à réécrire toutes mes librairies à chaque nouvelle version lorsqu'il n'y a pas de gains réels.
Avatar de Derek Corgan Derek Corgan - Membre éprouvé https://www.developpez.com
le 03/01/2018 à 19:22
Citation Envoyé par clementmarcotte Voir le message
Cela me rappelle l'historique "Bogue de l'an 2000", avec un tas de vieux programmes en COBOL fonctionnant avec des années codées sur deux chiffres, créés par des programmeurs qui voulaient sauver de l'espace mémoire rare et précieux. Les vieux programmes ont dû être corrigés dans l'urgence. Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées
Les programmes développés (lorsqu'ils parviennent en production) ont une durée de vie nettement supérieure à celle estimée par leurs auteurs et je suis bien placé pour le savoir. De plus les auteurs n'assument que rarement la maintenance de leur bébé (car tâche non valorisée). Un bug peut survenir des années après le développement (car test mal effectué lors du développement initial).

Citation Envoyé par clementmarcotte Voir le message
Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.

P.S. Là, j'ai mis le lien vers Radio-Canada, mais n'importe lequel média canadien (francophone ou anglophone) doit avoir son lot d'histoires d'horreurs de fonctionnaires avec pas de paye depuis une éternité ou des erreurs paye après paye.
Louvois, Chorus.... en France nous ne sommes pas mauvais dans le domaine.

Les mêmes causent produisant les mêmes effets.
Contacter le responsable de la rubrique Accueil