Discussion :

[Patrick Ruiz]

Le langage Go monte fortement en popularité d’après des données de l’index TIOBE
Mais semble ne pas l’être en France

Go, le langage de programmation compilé et concurrent inspiré de C et Pascal, vient de faire une percée remarquable en termes de popularité si l’on s’en tient à de récentes données de l’index TIOBE. Il occupe désormais la 10^e place de cet index avec un record historique de 2,363 % de parts de popularité devant des langages comme Perl, Swift, Ruby et Visual Basic.

Il faudrait noter que Go fait un bond du 55^e rang de l’index en juillet 2016 à son actuel – 10^e – rang. Tout observateur serait dès lors curieux de savoir si Go est capable d’aller – sur le long terme – chercher le quatuor de tête constitué de Java, C, C++ et C# depuis de nombreuses années maintenant ou dans un futur plus proche des langages comme JavaScript et Python eux aussi bien installés dans ce top 10 depuis un bon moment.

Si le langage Go – qui, faudrait-il le rappeler, a été élu langage de l’année 2016 par l’index TIOBE en raison de sa forte croissance dans le classement en comparaison à tous les autres – monte en popularité (du point des vues des données TIOBE), il faudrait souligner qu’il semble que ce ne soit pas le cas en France.

En effet, si l’on se réfère au sondage DVP 2015 sur le langage de programmation préféré, Go ne recueille que 0,43 % contre 27,8 %, 27,16 % et 25,22 % pour Java, C# et C++ respectivement.

Le sondage DVP 2016 sur les langages les plus « maîtrisés » – la communauté avait préféré le terme « manipulés » – épouse la tendance précédente. Go recueille 0,81 % contre 42,74 %, 38,71 % et 37,9 % pour Java, JavaScript et PHP respectivement.

Le sondage DVP 2017 sur les meilleurs langages de programmation confirme les tendances précédentes. Go recueille 6,32 %, bien loin du trio de tête constitué de Java, C# et C++ avec respectivement 33,2 %, 32,02 % et 21,34 %.

C’est dire que les développeurs de la communauté – et par extension, ceux de France – préfèrent, manipulent constamment et voient d’autres langages comme étant meilleurs que Go, toutes choses qui témoignent donc d’une certaine impopularité de ce dernier en France.

Comment comprendre qu’un langage qui a la même cible que C et C++ à savoir la programmation système – même s’il a été étendu aux applications – et qui de plus est, aux dires de ses concepteurs, « facile à comprendre et à adopter », soit apparemment aussi impopulaire en France ?

C++ est pourtant bien encré dans le top 5 des langages les plus populaires des différents index, que ce soit TIOBE ou PyPL.

Source : TIOBE

Et vous ?

Qu’est-ce qui d'après vous serait à l’origine de ce manque de popularité du langage Go en France ?

Voir aussi :

TIOBE : la popularité de Java et C est en baisse et Go en hausse depuis le début de 2016

TIOBE : Le langage de programmation Go de Google gagne en popularité favorisé par la popularisation de Docker

[grunk]

Pour moi le problème principal de Go c'est Google. Le projet à beau être open source il ont quand même le contrôle dessus. Et si demain leur besoin métier change il n'auront aucun problème à partir sur un Go n+1 qui casse complètement la rétro compatibilité avec la précédente version. On peut même imaginer que si demain Go n'a plus d'intérêt pour eux il ne le maintiendrons plus et sera simplement donné à la communauté qui devra se "débrouiller" avec.

Google est assez coutumier du fait , j'en prend pour exemple le passage de AngularJS à Angular 2,3,4 qui n' a pas laisser beaucoup de choix aux utilisateurs , même si la nouvelle version est de qualité.

[foetus]

Il me semble que le premier problème de Go c'est le système de paquets, surtout pour les modules tierces.

Donc Google a-t-il apporté une réponse ?

[Mickael Baron]

Salut,

Google est assez coutumier du fait , j'en prend pour exemple le passage de AngularJS à Angular 2,3,4 qui n' a pas laisser beaucoup de choix aux utilisateurs , même si la nouvelle version est de qualité.

Autre exemple avec GWT

Mickael

[abriotde]

Comme le dit grunk, les changement non rétrocompatibles d'AngularJS on fait une mauvaises pub à Google. Le bémol est que Google l'a massivement utilisé en son sein depuis longtemps il en est donc maintenant fortement dépendant.

La sagesse française qui adopte lentement ce langage se comprends aisément. Rappelons que les nouveaux langages concurrents de Go sont légions (Scala, Rust...) et que Go n'est pas si parfait que cela. Il est réputé créer des exécutable très lourd (un peu moins avec les dernières versions), performants mais beaucoup moins que C++, jeune et donc à l'avenir incertain (Google ayant souvent abandonné des projets).

Je ne vois pas Go comme un langage système, mais comme un langage productif pour des applications avec des besoins de performances. En cela il arrive en concurrence avec Java et C++ (qui sont moins productifs) sauf qu'il est beaucoup plus difficile de trouver des compétences Go.

[Mimoza]

Conf intéressante sur la pertinence de Go :

[evanboissonnot]

Bonjour

Je rejoins ce qui a été dit : partir sur tous langages ou techno ou appli que propose Google peut être risqué.
Google a la capacité de changer du jour au lendemain son langage ou ses langages.

Pareil pour angular js, je trouve impressionnant cette mode de l'Angular Js.
C'est encore risqué selon moi de s'y engouffrer completement.

Après c'est nouveau, donc c'est cool à apprendre, ça nous sort de nos habitudes, non ?

Vous avez déjà des retours de Go en entreprise, en France ?

A plus
Evan

[Gugelhupf]

@evanboissonnot,

Je comprends tes suspicions concernant Angular, tout ce qui est nouveau et différent est généralement un copycat de ce qui existe déjà, ce qui produit un effet de "apprendre pour réapprendre". Pourquoi un développeur Java changerait-il du jour au lendemain à C# et vice versa par exemple ? Pour ré-apprendre les mêmes fonctionnalités sous d'autres noms et patterns ?

J'étais développeur back avant de devenir ce qu'on appelle aujourd'hui "full stack". Et bien je peux te dire une chose, avec les technos front de type Angular/React/Vue, je n'ai juste plus envie de revenir en arrière. Développer avec des fichiers php, jsp, aspx, même accompagné d'un moteur de template tel que la JSTL, twig, mustache avec du jQuery etc ou même de passer par des frameworks orienté composant tels que JSF et GWT c'est du passé. Ces nouveaux frameworks front offrent des mécanismes d'une richesse inouïe et qui étaient peu exploités jusqu'à présent.

A+

[Mickael Baron]

@Gugelhupf,

J'étais développeur back avant de devenir ce qu'on appelle aujourd'hui "full stack"

C'est cool, tu vas pouvoir nous rédiger des articles ;-)

Mickael

[evanboissonnot]

@evanboissonnot,

Je comprends tes suspicions concernant Angular, tout ce qui est nouveau et différent est généralement un copycat de ce qui existe déjà, ce qui produit un effet de "apprendre pour réapprendre". Pourquoi un développeur Java changerait-il du jour au lendemain à C# et vice versa par exemple ? Pour ré-apprendre les mêmes fonctionnalités sous d'autres noms et patterns ?

J'étais développeur back avant de devenir ce qu'on appelle aujourd'hui "full stack". Et bien je peux te dire une chose, avec les technos front de type Angular/React/Vue, je n'ai juste plus envie de revenir en arrière. Développer avec des fichiers php, jsp, aspx, même accompagné d'un moteur de template tel que la JSTL, twig, mustache avec du jQuery etc ou même de passer par des frameworks orienté composant tels que JSF et GWT c'est du passé. Ces nouveaux frameworks front offrent des mécanismes d'une richesse inouïe et qui étaient peu exploités jusqu'à présent.

A+

Je comprends ton point de vue. Et pourquoi je me pose une vraie question sur la pertinence de tout ce code (souvent bien trop complexe, pour peu de chose en fait => mvc côté client WTF ?) ? Pourquoi alourdir un client qui devient de plus en plus un serveur ?
Concernant le react, je me suis formé au React et personnellement, je trouve que l'on arrive au max de la complexité pour pas grand chose.
Je suis dev full stack aussi, et pourtant j'ai toujours cette pensée sur la nécessité.

Je reviens souvent à faire du Back qui structure tout, et le FO qui affiche peu, pour moi le code métier doit être côté serveur

PS: as-tu fait des comparatifs de temps de dev, temps d'affichage entre une appli dev en react et une appli dev en php par exemple ?

A plus
Evan

[Gugelhupf]

Hello,

C'est cool, tu vas pouvoir nous rédiger des articles ;-)

Volontiers Mickael Par contre j'ai déjà trois tutoriels (Les exceptions web avec le framework Spring, Les Portlets avec Liferay 7, et La programmation orienté prototype en JavaScript) qui n'ont personne pour être relu ou corrigé


@evanboissonnot

Pourquoi alourdir un client qui devient de plus en plus un serveur ?

Tu préfères des applications où tes envois de formulaire font en sorte de faire générer au serveur des pages entières, auquel tu ajoutes le rafraichissement du DOM pour le client (appli web non-Angular-like), ou juste récupérer avec une très grande aisance des morceaux d'informations qui sont utiles à la page (appels Ajax avec un framework Angular-like).
Lequel est le plus "lourd" pour le client et serveur si tu prends en compte ces paramètres ?
Tu ne peux pas sacrifier le gain en heure de développement et maintenance parce que tu estimes qu'un framework front fait 150Ko (poids des frameworks React et AngularJS 1). Les navigateurs récents sont plutôt bien optimisé.

pour moi le code métier doit être côté serveur

Personne ne dira le contraire, si quelqu'un écrit du code métier coté front avec les applications Angular-like, c'est qu'il y a problème :/

As-tu fait des comparatifs de temps de dev, temps d'affichage entre une appli dev en react et une appli dev en php par exemple ?

Je ne me suis pas amusé à réécrire une même application deux fois, mais sinon oui c'est beaucoup plus rapide d'utiliser un framework Angular-like qui watch automatiquement des objets que d'aller soit-même récupérer à la main un élément du DOM à partir d'un selecteur pour faire en sorte qu'il exécute une action lors d'un évènement. Je n'observe aucune latence particulièreà l'oeil nu avec les applications Angular-like, les prises en compte lors d'un appuie de bouton sont immédiat par exemple.


A+

[honoré_princesse]

tes envois de formulaire font en sorte de faire générer au serveur des pages entières [...] ou juste récupérer avec une très grande aisance des morceaux d'informations qui sont utiles à la page (appels Ajax avec un framework Angular-like).

Ajax n'est pas né avec angular

[Gugelhupf]

Oui, mais c'est implicite avec les frameworks Angular-like. Encore une fois, ces frameworks front s'intègrent parfaitement au code HTML/CSS de la vue (point faible des frameworks orienté composant traditionnels) et font abstraction du DOM pour des besoins spécifiques.

[muad'dib]

Bizarre qu'on ne mentionne pas Scala dans cette étude (à moins qu'il ne soit classé avec les autres langages fonctionnels ?).

Je suis en recherche active pour changer de Job en ce moment et pas mal d'éditeurs de logiciels adoptent Scala pour leurs nouveaux projets.

Et comme dit auparavant dans ce fil, Google ne m'inspire personnellement pas confiance pour ses langages avec les changements "drastiques" qu'ils opèrent d'une version à l'autre. Dernière souffrance personnelle en date : Polymer 2.

[Madmac]

Bizarre qu'on ne mentionne pas Scala dans cette étude (à moins qu'il ne soit classé avec les autres langages fonctionnels ?).

Je suis en recherche active pour changer de Job en ce moment et pas mal d'éditeurs de logiciels adoptent Scala pour leurs nouveaux projets.

Et comme dit auparavant dans ce fil, Google ne m'inspire personnellement pas confiance pour ses langages avec les changements "drastiques" qu'ils opèrent d'une version à l'autre. Dernière souffrance personnelle en date : Polymer 2.

Cela pourrait t'intéresser: http://scalatra.org

Pour ma part, je ne crois pas que la prochaine évolution viendra d'un autre langage mais bien d'un autre modèle comme comme le modèle évènementiel comme VertX : http://vertx.io/

J'apprendrais Elixir plutôt que Go.