IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels avantages ou inconvénients trouvez-vous au langage Go ?
Schörghuber raconte son aventure avec Go et finit par le rejeter pour diverses raisons

Le , par Olivier Famien

316PARTAGES

13  0 
Go est un langage de développé par Google. Il est compilé, concurrent et inspiré des langages C et Pascal. L’objectif de ce langage a été résumé par Rob Pike, un des trois fondateurs de Go, lorsqu’il affirma que les jeunes développeurs « ;ne sont pas capables de comprendre un langage brillant, mais nous voulons les amener à réaliser de bons programmes. Ainsi, le langage que nous leur donnons doit être facile à comprendre et facile à adopter ;». Ainsi donc, ce langage se veut facile à dompter afin d’écrire des programmes surs.

Depuis sa sortie en 2009, Go a connu une forte adoption dans la communauté des développeurs et se classe ce mois-ci à la 16e place dans le classement de l’Index Tiobe. Lukas Schörghuber fait partie de ces personnes qui ont porté leur dévolu sur ce langage depuis des années et en ont fait leur langage favori. Après l’avoir utilisé dans plusieurs projets, Schörghuber nous livre son sentiment sur les avantages et les inconvénients de GO.

Des avantages très intéressants

Pour ce qui concerne les avantages de Go, Schörghuber en trouve plusieurs. Étant conçu pour la programmation concurrente, Go est très excellent lorsqu’il s’agit de gérer les threads. Sa capacité à pouvoir utiliser des threads légers afin de gérer les messages provenant de plusieurs plateformes dans une architecture client-serveur est la raison principale qui a poussé Schörghuber à s’intéresser véritablement à ce langage.

Une fois résolu dans son projet de s’investir dans Go, Schörghuber a été sidéré par la facilité avec laquelle il a pu déployer son application Go. Un simple téléchargement du binaire sur le serveur ou une inclusion du binaire dans l’image du conteneur suivi d’une configuration standard et le tour est joué. Aucune gestion complexe du runtime ou autre péripétie n’est nécessaire. Bien évidemment, l’on ne fait pas référence à la création d’utilisateurs, l’ajout de firewall, ou encore à la sauvegarde de la base de données qui peuvent se faire en une seule fois et ne sont pas vraiment liés à la programmation.

Comme autre avantage cité par Schörghuber, le développeur met en avant la facilité d’installer les applications Go sur différents systèmes comme Windows et Linux. Une simple commande comme go install <applicationName> est suffisante pour exécuter l’application, peu importe que ce soit sur Linux ou Windows.

Passé ces différents points positifs de Go, Schörghuber a été négativement frappé par plusieurs aspects du langage qui ont vite fait de lui faire oublier l’enthousiasme qu’il avait en s’engageant dans cette aventure avec Go.

Des inconvénients qui font méditer

D’abord, le développeur note que Google souhaite imposer son style de codage à ceux qui utilisent Go. Généralement, chaque développeur adopte son style en fonction des conseils et des déductions personnelles faites à travers les années d’expérience. Schörghuber pour sa part a adopté son style en suivant les conseils de son professeur et en établissement des codes de bonnes pratiques tirés des années d’expérience en tant que développeur. Toutefois, ce dernier souligne qu’avec Go, lorsque vous placez un crochet ouvert sur une nouvelle ligne, cela provoque une erreur de syntaxe. De même, si vous commencez une concaténation de chaîne de caractères sur une nouvelle ligne, l’éditeur de code génère une erreur de syntaxe. Pour Schörghuber, cela est inacceptable que Google oblige les développeurs à adopter un style de codage particulier pour éviter ces erreurs. Selon lui, cela devrait être une suggestion et non une obligation.

La seconde chose qui a laissé un goût amer à Schörghuber est le gestionnaire de paquets. Un des gros avantages de ce dernier est qu’il fonctionne de manière transparente en allant chercher directement les dépendances de code à partir du système hôte ou des dépôts Git. Mais son gros inconvénient, selon Schörghuber, est qu’il n’existe aucun moyen de déterminer la version d’un paquet. Go résout ce problème en s’appuyant sur la version principale, mais lorsque des changements surviennent au niveau de cette branche principale, l’application ne compile plus, précise Schörghuber.

Un autre problème qui pourrait sembler trivial pour certains est rapporté par Schörghuber comme très gênant pendant la programmation. Il s’agit de l’absence de la notion d’héritage des objets. Alors que beaucoup diront qu’il n’a qu’à faire du copier-coller pour régler son problème, Schörghuber trouve vraiment aberrant d’avoir à écrire beaucoup de code dupliqué. Une solution qui lui a permis de régler ce problème d’héritage au niveau des méthodes d’objets est l’usage d’interface, mais pour les membres de données il n’a pas trouvé de solutions qui lui facilitent la vie.

Un autre boulet qui pousse Schörghuber à prendre ses distances vis-à-vis de Go est la non-prise en charge du concept de généricité. Pour le développeur, les créateurs de Go et sa communauté devraient prendre en charge ce concept dans la mesure où ils présentent Go comme un langage dynamique.

Enfin, Schörghuber explique comme dernier point qui a achevé de le convaincre d’abandonner Go est l’absence de certains composants dans la bibliothèque HTTP. Pour créer de simples services HTTP, la bibliothèque Go fait aisément l’affaire. Mais si vous voulez aller plus loin et ajouter des fonctionnalités comme des paramètres de style REST, des cookies ou encore des sessions, des plug-ins supplémentaires sont nécessaires, explique le développeur.

Et le comble dans cette affaire, précise Schörghuber, il n’y a aucune mention de ces choses absentes dans la documentation. Aussi, en voulant implémenter certaines fonctionnalités avec la bibliothèque HTTP, vous pourriez avoir des erreurs qui prendront des heures à dépanner en raison de ce manque d’information dans la documentation Go.

Après avoir pesé tous les avantages et les inconvénients de Go, Schörghuber a décidé d’abandonner ce langage qui lui a donné tant de satisfaction au départ. L’expérience étant variable en fonction des personnes, quelles sont les raisons qui vous ont poussé à adopter Go ;? Ou à vous en éloigner ;?

Au-delà du langage Go, quelles sont les raisons qui peuvent pousser un développeur à apprendre un langage ou à le rejeter ;?

Source : Blog de Lukas Schörghuber

Et vous ?

Pour quelles raisons avez-vous choisi d’apprendre Go ;? Quels sont les avantages que vous lui trouvez ;?

Avez-vous abandonné Go ;? Pour quelles raisons ;?

De manière générale, quels sont les éléments qui peuvent pousser un développeur à apprendre ou vomir un langage ;?

Voir aussi

Go : le langage de programmation de Google va à l'assaut du mobile, Go 1.4 introduit le support d'Android
TIOBE : Le langage de programmation Go de Google gagne en popularité, favorisé par la popularisation de Docker
Apprendre la programmation en langage Go par l'exemple, un tutoriel de Clement Keirua

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de redbullch
Membre confirmé https://www.developpez.com
Le 11/08/2017 à 14:00
Lors de la devoxx FR 2017, un employé de docker (Jean-Laurent de Morlhon) explique son expérience avec Go.



Il parle de la plupart des points évoqués dans cette discussion (avec un brin d'humour).
5  0 
Avatar de JCD_31
Membre averti https://www.developpez.com
Le 11/08/2017 à 8:26
Pour avoir pratiqué ce langage pendant deux ans dans un service R&D, j'ai beaucoup apprécié et je m'en sers toujours dans mes projets personnels (et professionnels quand l'occasion se présente).
Je suis d'accord avec les avantages qu'il évoque. Je pourrais en citer d'autres comme l'abondance de fonctionnalités de bases absentes dans d'autres langages ou encore la légèreté de compilation ou d'exécution.

Mais je suis moyennement d'accord avec ses inconvénients :

- Style de codage
Pas du tout d'accord. Chaque langage a ses particularités et c'est au développeur de s'adapter. Si je me trompe pas, par exemple Python, si l'indentation n'est pas réalisée correctement, il y aura des erreurs de compilation. Mettre à la ligne un crochet est un débat éternel JAVA vs C. Quand à mettre des chaines sur plusieurs lignes, par exemple, possible en Java, c'est moche. Je préfère utiliser un StringBuilder, chose possible en Go.

- Gestionnaire de paquets
Là malheureusement, je ne peux que lui donner raison. Le gestionnaire de paquets est bien pénible...

- Héritage des objets & Généricité
Ayant pratiqué le C pendant longtemps, cet aspect du langage ne m'a pas choqué. On peut toujours simuler cette notion via des structures (comme en C).

- Manque de fonctionnalités avancées dans HTTP & non mentionnés dans la documentation
Pas du tout d'accord là aussi. J'ai réalisé un serveur HTTP avec une API REST avec une simplicité enfantine. Je ne vois pas le problème d'utiliser une bibliothèque extérieure...
Je suis d'accord toutefois pour la documentation.
3  0 
Avatar de dolanor
Membre habitué https://www.developpez.com
Le 10/04/2018 à 12:55
Désolé de revenir après la pluie, mais je voudrais exposer un autre point de vue par rapport à plusieurs éléments dans ce message.

La normalisation du code pourquoi pas (quoique inutile à mon avis),
Pour moi, c'est loin d'être inutile. Quand on code, on passe combien de temps à lire, on passe combien de temps à coder ? Pour moi, je dirais 70-80% de lecture pour 20-30% de code, À moins d'être toujours le premier développeur sur des projets qui part au bout de 2 mois et n'a pas à maintenir du code (et qui en plus a le luxe de tout développer depuis 0, parce qu'il ne prend aucune dépendance).
Si en passant d'un package/module à un autre, d'une dépendance à une autre on a 4 styles différents, voilà le mal de tête et on essaye de rentrer 4 concepts différents qui décrivent la même chose, du code.
Depuis Go, je lis quasiment tous les code de mes dépendances à un moment ou un autre, et je ne suis que très peu ralenti. Alors qu'à mon époque de C++, lire une implémentation d'une lib réseau plutôt orientée C puis switcher sur de l'interface graphique des années 80 et essayer de porter du Qt dessus tout en adaptant un data layer générique basé sur du NoSQL des années 80 (aka C-ISAM). Bah, c'était pas le même temps de lecture et donc de travail.

Ça oblige à introduire d'autres incongruités syntaxiques tel que le fait d'avoir à ajouter des "," en fin de ligne d'une énumération ou liste de paramètres même si il n'y a pas d’élément suivant. Et ce, juste pour que le retour à la ligne ne soit pas interprété comme une fin d'instruction
Ce n'est pas la seule raison, ça a le deuxième effet kisscool de pouvoir supprimer la dernière ligne sans avoir à éditer la ligne du dessus pour enlever la dernière ",". Ça fait des diff plus clair à reviewer et c'est plus facile à exécuter dans un éditeur avec des bons raccourcis clavier.


Tout ça étant d'autant plus idiot qu'aujourd'hui les IDEs permettent de reformater le code comme on le souhaite, avec ses propres règles et que la normalisation de la présentation du code à donc peu d'intérêt en soit si on y réfléchit bien.
Et M. A adore le K&R alors que M. B préfère la syntaxe C++/java. Et hop, pour pouvoir relire le code de M. A, M. B active son formattage dans son IDE, code sa partie et commit son code. Youpi, un joli commit présentant une modification de 95+% du fichier alors qu'une ligne a été changée. (déjà vu plein de fois, et faire de la revue de code la dessus, c'est juste fatiguant)

Tout ça vient bien sûr de mon expérience personnelle, et aussi, je suis un fan de Go et de sa simplicité en règle générale, donc mon avis est biaisé :p.
3  0 
Avatar de JCD_31
Membre averti https://www.developpez.com
Le 11/08/2017 à 10:45
Citation Envoyé par vendomele Voir le message
Non et non, un développeur s'adapte à la syntaxe, mais n'a nullement besoin de modifier sa façon d'écrire, utiliser l'exemple de python, c'est mesquin,
il n'y a pas de caractère ou de mot clé pour définir un bloc, d'où l'utilisation de tab, mais je considère que c'est une syntaxe et non un style d'écriture.

Quand j'ai voulu apprendre GO et que j'ai constaté qu'on devait adopter un style d'écriture pour que cela ne soit pas considéré comme une erreur, j'ai arrêté tout de suite GO.

Alors les avantages je les ignores, mais j'ai trop d'années d'expérience pour qu'on m'interdise d'utiliser mon style.
Pour ma part, imposer un style, je vois ça comme un avantage. J'en ai plus qu'assez d'entendre au boulot des débats incessants sur le placement des crochets, le placement des étoiles pour les pointeurs ou encore des espaces avant/après les blocs. Il y en aura toujours qui ne seront pas satisfait de ce que fait le collègue. Là, Go met tout le monde d'accord.
2  0 
Avatar de delta07
Membre régulier https://www.developpez.com
Le 17/08/2017 à 13:35
La raison pour laquelle Google a choisi d'imposer une certaine formalité est simplement que les gens sont capables de s’entre tuer et de pinailler sur ladite syntaxe (cf le topic...) sans prendre en considération les avantages/inconvénient du langage en question.

Refuser de tester/adopter un langage sous prétexte qu'on nous oblige à mettre l'accolade à la fin ou au début... ça m'évoque surtout une réaction puérile et non professionnelle.

Encore une fois, je n'ai pas tester plus que ça, ça n'est que mon avis. Je trouve juste dommage de se braquer pour un truc aussi bête.

Citation Envoyé par Laurent Simon  Voir le message
Tout à fait normal pour ces cas:

  • En XML: le format des balises fait partie de la syntaxe, mas on reste totalement libre de la présentation du code.
  • En Python: La tabulation fait partie de la syntaxe. Elle n'est donc pas utilisable comme élément de présentation puisque qu'une sémantique lui est associée. C'est la contre partie à payer pour l'absence d'accolades ou d'équivalent. Le rôle de la tabulation y est clair et cohérent.
  • En java: Le ";" est un élément syntaxique. Ce qui n'a rien à voir avec la façon de rédiger le code. Ce n'est pas de la présentation! On doit mettre un ";" à la fin de chaque instruction, mais on le met où on veut.


Avec Go, la façon de rédiger le code fait en quelque sorte partie de la syntaxe, mais d'une façon abominable. Pour l'usage du retour à la ligne, on n'est plus comme dans le cas de Python où un caractère particulier (la tabulation) a une signification. Avec Go, la syntaxe autorise le retour à la ligne à des fins de présentation dans certains cas particuliers ( après les symboles ".,({[" ou un opérateur binaire). Dans tout autre cas, un retour à la ligne équivaut à un ";". La syntaxe Go est donc bancale. Le "retour à ligne" n'a pas de sémantique associée, mais par endroits il fait partie de la syntaxe (sans sémantique associée, juste pour faire chi... ), dans d'autres il prend une sémantique implicite (la même que ";" en l'absence de celui-ci en fin de ligne), et ce, sans aucune raison valable autre que de dicter une présentation du code. Là, pour moi c'est clairement NON.

Et tu auras beau argumenter dans tous les sens, tu te braques parce qu'on t'oblige à mettre une accolade à la fin... Il y'a certainement moyen de débattre plus intelligemment sur ce langage.
2  0 
Avatar de mh-cbon
Membre extrêmement actif https://www.developpez.com
Le 11/08/2017 à 8:58
Citation Envoyé par JCD_31 Voir le message

- Style de codage
Pas du tout d'accord. Chaque langage a ses particularités et c'est au développeur de s'adapter. Si je me trompe pas, par exemple Python, si l'indentation n'est pas réalisée correctement, il y aura des erreurs de compilation. Mettre à la ligne un crochet est un débat éternel JAVA vs C. Quand à mettre des chaines sur plusieurs lignes, par exemple, possible en Java, c'est moche. Je préfère utiliser un StringBuilder, chose possible en Go.
J'ai été choqué pendant pendant quelques semaines, désormais je ne plus passer sur un autre langage sans manquer cette fonctionnalité de formatage à la sauvegarde.
Plus de pertes de temps, plus de questions, plus de prises de têtes, un truc qui juste fonctionne, basta?

Citation Envoyé par JCD_31 Voir le message

- Gestionnaire de paquets
Là malheureusement, je ne peux que lui donner raison. Le gestionnaire de paquets est bien pénible...
cf dep, glide, godeps. Ce n'est pas dans la build chain, mais c'est du standard, qui fait son job.

Citation Envoyé par JCD_31 Voir le message

- Héritage des objets & Généricité
Ayant pratiqué le C pendant longtemps, cet aspect du langage ne m'a pas choqué. On peut toujours simuler cette notion via des structures (comme en C).
Marrant c'est le truc qui me manque le moins, les arbres de types hiérarchique. Pour ce qui est des generics je pense aussi qu'il manque quelque chose, mais je n'imagine pas qu'ils backportent un genre de java generics comme php4 à fait un truc similaire en son temps avec le modèle objet.

Citation Envoyé par JCD_31 Voir le message

- Manque de fonctionnalités avancées dans HTTP & non mentionnés dans la documentation
Pas du tout d'accord là aussi. J'ai réalisé un serveur HTTP avec une API REST avec une simplicité enfantine. Je ne vois pas le problème d'utiliser une bibliothèque extérieure...
Je suis d'accord toutefois pour la documentation.
Doc super lourde au début, une fois qu'on la connaît mieux c'est moins désagréable. Pour le reste lire que la stdlib ne supporte pas les cookies est un des signes de la faiblesse de l'article original, https://golang.org/pkg/net/http/#Request.Cookie ?

Sinon, `go get ...` pour installer les paquets, c'est bien pour faire mumuse, au delà c'est le bourbier, c'est foireux comme argument.

Un autre problème qui pourrait sembler trivial pour certains est rapporté par Schörghuber comme très gênant pendant la programmation. Il s’agit de l’absence de la notion d’héritage des objets. Alors que beaucoup diront qu’il n’a qu’à faire du copier-coller pour régler son problème, Schörghuber trouve vraiment aberrant d’avoir à écrire beaucoup de code dupliqué. Une solution qui lui a permis de régler ce problème d’héritage au niveau des méthodes d’objets est l’usage d’interface, mais pour les membres de données il n’a pas trouvé de solutions qui lui facilitent la vie.
Une des maximes du langages est qu'il vaut mieux un petit copié collé qu'une grosse solution compliquée.

A résultats équivalent le copié collé est plus simple, moins cher et fonctionne mieux que la solution compliquée.

Cependant, comment peut on dire qu'il manque "l'héritage" alors que visiblement la notion de composition n'est pas acquise ? `au niveau des méthodes d’objets est l’usage d’interface...` un contrat d'api ? Ou une interface{} ?
derrière cette question de circonstance il y a une vraie plaie dans ce langage, la double utilisation du mot interface

Autrement, je pense que le langage manque de richesse dans l’écosystème de librairies, java/c++ sont très fort la dessus.
1  0 
Avatar de delta07
Membre régulier https://www.developpez.com
Le 11/08/2017 à 18:57
Très bonne vidéo pour le coup !
1  0 
Avatar de GilbertLatranche
Membre averti https://www.developpez.com
Le 12/08/2017 à 11:28
Non content d'avoir une mascotte insupportable, Go profite de toute une communauté de webdevs insupportables incultes qui chouinent contre toute évolution sensée du langage.
1  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 17/08/2017 à 1:47
Je développe depuis une trentaine d'années essentiellement sous Unix (ou Linux), beaucoup de C, du Smalltalk-80, puis re du C, beaucoup de java, du javascript, plus récemment python et un peu par curiosité après avoir vu que Ken Thompson faisait partie de concepteurs du langage, je me suis lancé sur go pour quelques petits projets il y a deux trois mois. En parallèle et depuis toujours j'écris beaucoup de code en shell et awk.

Je dois reconnaître que je suis agréablement surpris par golang.

La standardisation du formattage des sources ne me gène pas. Ç'est au contraire un progrès qui facilite la lisibilité et l'échange de code. Je serais contrarié si on m'imposait ma manière d'indenter, la présence d'espaces ou non, la position des accolades... mais la syntaxe de go rompt suffisamment avec celle du C (et des langages qui s'en sont inspiré comme awk/C++/java/javascript/etc.) pour que ça ne soit pas un problème. C'est un peu comme python, il suffit de se dire que ça fait partie du langage et ça passe bien.

Le langage est très intuitif et les évolutions par rapport au C vont dans le sens d'une simplification assez agréable. Par exemple, l'air de rien, le typage automatique avec := et le formattage par "%v" facilitent beaucoup la vie.

L'intégration de la cross compilation et le peu de dépendance à l'OS, combinés à l'autonomie de binaires produits sont absolument géniaux. Je peux générer un .exe sous Linux et l'envoyer à quelqu'un qui travaille sous windows qui n'aura besoin de rien installer d'autre que ce fichier exécutable pour le faire fonctionner. C'est le jour et la nuit avec les autres langages avec lesquels il faut avoir installé au préalable sur la cible des environnements d'exécution et des bibliothèques pour espérer que que ça tourne.

Le compilateur et le code généré sont rapides. "go build" se débrouille en général bien tout seul pour trouver ce qu'il faut compiler et linker, "go get" va chercher et compiler des bibliothèques externes de manière très simple.

Je suis tombé un jour sur un bug dans une bibliothèque graphique que j'avais trouvé sur github. J'ai juste eu à modifier deux ou trois lignes dans le source de la bibliothèque qui était dans mon GOHOME pour contourner le bug et puis j'ai recompilé la bibliothèque avec un "go build", regénéré mon binaire et c'est tout. Avec d'autres langages, j'en serais peut-être encore à me battre pour télécharger les sources, comprendre comment recompiler, gérer les dépendances, etc.

Quelques inconvénients:

- l'absence de débogueur intégré standard. C'est un gros retour en arrière, je remet des printf à droite à gauche comme à mes débuts... Je viens de regarder delve, ça a l'air de marcher mais je préfèrerais un support correct par gdb.

- La compilation en statique uniquement. C'est la contrepartie d'un des avantages cités plus haut, production fichier exécutable autosuffisant. S'il y a une faille de sécurité ou un bug dans une bibliothèque utilisée, il faut recompiler et livrer. Avec d'autres langages, la mise à jour d'un .so ou .dll peut corriger le programme de manière transparente.
1  0 
Avatar de JCD_31
Membre averti https://www.developpez.com
Le 11/08/2017 à 9:56
Citation Envoyé par mh-cbon Voir le message
cf dep, glide, godeps. Ce n'est pas dans la build chain, mais c'est du standard, qui fait son job.
Ouep, je me suis mis à Godeps après. Mais j'ai pas mal galéré sur certaines librairies spécifiques.
0  0