Discussion :

[codec_abc]

Les concepteurs de Go ont beaucoup d'expérience (parmi les plus expérimentés à Google) - et ce n'est pas forcément la même que vous ! Évitez les attaques trop simples, c'est souvent le signe que vous n'avez pas compris les objectifs du langage.

Je n'ai pas trop l'impression que les concepteurs de Go aient tant que ça d'expérience en création de langage de programmation. A contrario, Anders Hejlsberg après Delphi et C# il est passé sur Typescript (qui hormis les "défauts" pour être compatible avec Js) est un langage encore plus poussé, ce qui semble plutôt montrer que c'est en rajoutant des features qu'on aide les développeur dans leur travail. Mais surtout j'ai bien compris les objectifs du langages. C'est juste que pour moi Go n'a pas de raison d'exister et résout un problème inexistant. Des langages terre à terre ça fait un moment que l'on en a eu un paquet (Basic ça remonte au années 70) et à part les goroutines on peut écrire du "Go like" dans n'importe quel langage, il suffit juste de se limiter a ne pas utiliser la majorité des features. Après concernant la maintenance, il y a une part de vérité dans ce que tu dis (forcément que le code trivial est plus facile à maintenir) mais il faut aussi reconnaitre que Go est tellement verbeux que pour le même problème tu vas avoir plus de lignes à maintenir en Go. Et encore pour la maintenance, je réitère que sa trop grande simplicité est à double tranchant. En Go on se trouver avec les pointeurs des void* en C pour les structures génériques ou il faut le caster dans le bon type pour pas que ça fasse n'importe quoi. C'est hyper sujet à l'erreur et ça ne se détecte qu'au runtime.

[Dymmm]

Je n'ai pas trop l'impression que les concepteurs de Go aient tant que ça d'expérience en création de langage de programmation. A contrario, Anders Hejlsberg après Delphi et C# il est passé sur Typescript (qui hormis les "défauts" pour être compatible avec Js) est un langage encore plus poussé, ce qui semble plutôt montrer que c'est en rajoutant des features qu'on aide les développeur dans leur travail. Mais surtout j'ai bien compris les objectifs du langages. C'est juste que pour moi Go n'a pas de raison d'exister et résout un problème inexistant. Des langages terre à terre ça fait un moment que l'on en a eu un paquet (Basic ça remonte au années 70) et à part les goroutines on peut écrire du "Go like" dans n'importe quel langage, il suffit juste de se limiter a ne pas utiliser la majorité des features. Après concernant la maintenance, il y a une part de vérité dans ce que tu dis (forcément que le code trivial est plus facile à maintenir) mais il faut aussi reconnaitre que Go est tellement verbeux que pour le même problème tu vas avoir plus de lignes à maintenir en Go. Et encore pour la maintenance, je réitère que sa trop grande simplicité est à double tranchant. En Go on se trouver avec les pointeurs des void* en C pour les structures génériques ou il faut le caster dans le bon type pour pas que ça fasse n'importe quoi. C'est hyper sujet à l'erreur et ça ne se détecte qu'au runtime.

Je trouve personnellement que l’existence de Go est tout à fait justifié en remplacement du C la où il n'y a pas de majorité de codeurs pointus toujours disponibles. Pourquoi prendre un langage plus complexe a prendre en main si celui ci suffit ? On peut écrire du Go like en C, avec une certaine discipline, mais franchement, si tous les dev étaient si disciplinés nous n'aurions besoin que du C++ pour tout. Pour moi le Go existe pour permettre l’implémentation de solution simple sans s'ennuyer avec des détails techniques que, finalement, peu de dev maitrise n'interressent pas tous les dev.

EDIT : j'ai été trop pessimiste / lassé dans mon poste d'origine

[Pyramidev]

Je n'ai pas trop l'impression que les concepteurs de Go aient tant que ça d'expérience en création de langage de programmation.

Parmi les 3 créateurs du Go, Ken Thompson a créé le langage B avec Dennis Ritchie.

Mais, à mon avis, le plus important, ce n'est pas d'avoir de l'expérience en création de langage, mais d'avoir une culture générale solide sur les langages enrichissants, y compris ceux qui sont peu utilisés dans l'industrie. Par exemple :

• Haskell est intéressant pour la programmation fonctionnelle, pour son système de type et pour le niveau d'abstraction élevé de sa bibliothèque standard.
• D est intéressant pour la programmation générique, la métaprogrammation et ses très nombreuses fonctionnalités.
• Les dialectes du Lisp sont intéressants pour la métaprogrammation basée sur les syntactic macros.
• Rust (sorti après Go) est intéressant pour ses contrôles stricts à la compilation alors qu'il supporte le bas niveau comme le C.

à part les goroutines on peut écrire du "Go like" dans n'importe quel langage, il suffit juste de se limiter a ne pas utiliser la majorité des features.

« N'importe quel langage », c'est trop large. Les interfaces de Go sont une forme de polymorphisme au runtime qui facilite la création de types parents a posteriori sans modifier le code du type enfant, le tout avec du typage statique. Ce n'est pas le seul à savoir le faire et ce n'est pas celui qui le fait le mieux (à cause des risques de sous-typage accidentel), mais ce n'est pas une fonctionnalité si répandue que ça.
Par exemple, en Java, pour ajouter un type parent (typiquement une interface) à une classe existante, il faut modifier le code de cette classe pour dire qu'elle implémente cette interface. Si modifier le code de cette classe n'est pas possible ou pas souhaitable, alors on doit l'encapsuler dans un wrapper qui implémentera cette interface. Ce n'est pas très flexible quand on doit gérer des hiérarchies d'interfaces.

On peut écrire du Go like en C, avec une certaine discipline

Le langage C décourage le polymorphisme. Dès que l'on veut faire du polymorphisme en C, le code devient hyper verbeux car il faut tout bricoler à la main.

mais franchement, si tous les dev étaient si disciplinés nous n'aurions besoin que du C++ pour tout.

Pas pour tout. Par exemple, si j'écris un petit script en Python au lieu de l'écrire en C++, ce n'est pas pour des raisons de discipline.

[LLB]

Mais, à mon avis, le plus important, ce n'est pas d'avoir de l'expérience en création de langage, mais d'avoir une culture générale solide sur les langages enrichissants, y compris ceux qui sont peu utilisés dans l'industrie.

Bien sûr. Si tu prends le design sur les generics, il ont écrit pas mal de documents depuis des années. Tu te doutes bien qu'ils ont étudié les solutions des autres langages et qu'ils ont beaucoup de retours d'autres gens. En l'occurrence, ils citent quelques langages dans le dernier document : https://go.googlesource.com/proposal...ther-languages

[mox20]

Bonjour,

J'ai lu beaucoup d'articles sur ce site à propos de Go, souvent les gens le criquent parce qu'ils le trouvent un peu de contre nature quand ils sont habitués à la POO de leur language favori, en fait beaucoup ne connaissent pas suffisamment ce longue je pense. C'est un langage magnifique qu'on peut apprendre facilement, même si au début on a l'impression d'être perdu, en réalité une qu'on a bien compris le langage, on peut faire des choses magnifique avec sans aller ce casser le c... à gérer la mémoire ou installer des choses pour le faire fonctionner sur d'autres machines ou systèmes.

J'ai beaucoup développé en PHP principalement de la POO, j'ai essayé Python, un jour le me suis dis je dois apprendre un langage qui me permettra de faire beaucoup de choses tout en étant robuste et rapide, j'ai voulu apprendre le C, C++, Java, franchement je n'ai pas arraché, soit trop complexe, soit trop lourd (Java), alors j'ai fait le chois de Golang, mon dieu que c'est le pied de faire ça :

Code :

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

1
2
	go server.coursCoucou()
	go server.coucouVasPasBloquer()

Avec Go, j'ai réalisé un petit CMS en 1 mois alors que je débutais avec ce langage ! De plus celui embarque un sacré serveur web magique ! Des programme de chiffrement en quelques jours et le plus kiffant que j'ai réalisé il a quelques jours c'est un système client/serveur/tcp de backup pour faire des sauvegardes de mon serveur distant la synchronisation est quasi instantanée tout ceci sans être ingénieur ni informaticien, je suis électricien à la base ! C'est ça la vraie force de Golang ! La simplicité et rapidité. Aujourd'hui je fais quasiment tout avec Go, je code Go, je pense Go et je reve Go Car j'ai une mission désormais : développé des programmes Go avec des interfaces graphiques, purée ça doit être le pied ça ! un simple "go install" ou "go build" ou encore "GOOS=darwin go build" pour la pomme fera affaire. C'est quand même une révolution non ? Puis Go permet contrairement à ce pensent certains, de faire de la programmation objet et gérer l'héritage. Bref vive Golang !

[Michael Guilloux]

L'équipe Go revient sur le processus de développement de la version 2.0 du langage
et soumet des changements à venir dans Go 1.13

Développé par Google, Go est un langage de programmation compilé et concurrent inspiré de C et Pascal. Il a été créé avec pour objectif de permettre aux développeurs, même ceux qui n'ont pas d'expérience, d'écrire facilement de bons programmes.

Depuis sa sortie en 2009, Go a connu une forte adoption, du moins d'après les différents baromètres. Mais le langage est relativement jeune et il a encore beaucoup à faire pour séduire les développeurs et entreprises. Google travaille donc pour y parvenir, et pour annoncer cela, la firme a commencé par travailler sur l'image de son langage, en se dotant d’un nouveau logo en avril dernier. Mais les efforts des développeurs de Go sont plus concentrés sur la version 2 du langage.

Le processus de réflexion sur la prochaine grande version de Go a été officiellement lancé l'année dernière, et fin août, Google a partagé des informations (un brouillon) sur la conception de Go 2, qui abordaient des thèmes importants comme la programmation générique et une meilleure prise en charge de la gestion des erreurs. Dans un récent billet de blog, Robert Griesemer, l'un des créateurs du langage, est revenu sur le processus de développement de Go et la manière dont les fonctionnalités seront livrées aux développeurs.

Go 2 ne viendra pas comme une seule version majeure, ses fonctionnalités arriveront de manière incrémentale

Ce qu'il faut savoir, c'est que Go 2 ne viendra pas comme une version majeure avec un tas de fonctionnalités majeures qui vont casser la compatibilité avec les versions précédentes. Oui, ce serait un peu brusque, et c'est d'ailleurs l'une des raisons pour lesquelles les développeurs sont réticents à adopter de jeunes langages ou technologies.

« Nous avons appelé ce futur langage de manière informelle Go 2, même si nous comprenons maintenant qu’il arrivera de manière incrémentale plutôt qu'avec un big-bang (un changement radical, NDLR) et une seule version majeure », explique Robert Griesemer. « Néanmoins, Go 2 est un surnom utile, ne serait-ce que pour avoir un moyen de parler de ce futur langage, alors continuons de l’utiliser pour le moment », dit-il.

En 2015, l'équipe Go a introduit un processus de proposition afin de recueillir un type de retour spécifique : les propositions de modification de langage et de bibliothèque. Un comité composé de membres éminents de l'équipe Go a ainsi été chargé d'examiner, catégoriser et décider des propositions entrantes sur une base régulière. Cela fonctionnait assez bien, mais dans le cadre de ce processus, ils ont ignoré toutes les propositions qui n'étaient pas compatibles avec les versions précédentes du langage. Ces propositions ont simplement été marquées avec la mention "Go 2", ce qui suggère qu'ils seraient intégrés dans Go 2.

Actuellement, il y a environ 120 propositions marquées "Go 2". Les propositions liées ont été fusionnées et celles qui semblaient clairement hors de la portée de Go ou qui ne pouvaient pas être gérées ont été fermées. Mais les propositions restantes vont probablement influencer les bibliothèques et le langage et, dans certains cas, ne vont pas permettre de satisfaire la garantie de compatibilité existante de Go 1.

Comme nous l'avons déjà dit, deux grands thèmes sont ressortis très tôt de ces propositions : la prise en charge d'une meilleure gestion des erreurs et les génériques. Mais il y en a bien d'autres. Alors qu'en est-il du reste ? Une question à laquelle répond le co-créateur de Go :

« Nous sommes limités par le fait que nous avons maintenant des millions de programmeurs Go et un vaste corpus de code Go, et que nous devons continuer dans cette voie, sans quoi nous risquerions un écosystème scindé. Cela signifie que nous ne pouvons pas faire beaucoup de changements, et les changements que nous allons faire doivent être choisis avec soin », explique M. Griesemer. Pour progresser, l'équipe Go met donc en place un nouveau processus d'évaluation des propositions pour ces changements potentiels importants.

Si Go 1 était donc un petit effort d'équipe avec une influence extérieure modeste, Go 2 sera beaucoup plus axé sur la communauté ; laquelle communauté pourra désormais influencer la conception et la façon dont les décisions sont prises, d'après Robert Griesemer.

Des propositions marquées "Go 2" seront publiées dans Go 1.13

Vu le défi à relever, l'équipe Go a décidé de commencer par un petit nombre de propositions de modification de langage compatibles avec les versions antérieures. « Cela fait longtemps que nous n’avons pas fait de changement dans le langage, alors cela nous ramène à ce mode. De plus, les changements ne nécessiteront pas que nous nous inquiétions de casser le code existant ».

Cela dit, elle soumet une petite sélection de propositions Go 2 qui seront publiées dans Go 1.13 - rappelons encore que les fonctionnalités de Go 2 seront livrées de manière incrémentale pour éviter tout changement radical. Les propositions concernent :

• l'adoption des identifiants Unicode généraux basés sur Unicode TR31 : cela corrige un problème important pour les programmeurs Go utilisant des alphabets non occidentaux et devrait avoir peu d’impact sur les autres développeurs ;
  
  
• les littéraux entiers binaires et prise en charge de _ dans les littéraux numériques : il s'agit selon l'équipe Go de modifications relativement mineures pour ajouter des fonctionnalités qui semblent extrêmement populaires chez les développeurs. Ils ne viennent pas résoudre un « problème important », estime Robert Griesemer, mais ils rapprochent Go de la plupart des autres langages à cet égard et peuvent soulager certains programmeurs. Ils ont en plus un impact minimal sur les autres utilisateurs indifférents au littéral entier binaire ou au formatage numérique, et la mise en œuvre est bien comprise ; et
  
  
• la modification de la spécification du langage de telle sorte que l'opérande de droite dans une opération << ou >> puisse être un entier (non constant) signé ou non signé, ou toute valeur constante non négative pouvant être représentée par un nombre entier.

En vertu du nouveau processus, ces propositions étant faites, c’est maintenant à la communauté Go de donner son avis. Pour chaque proposition pour laquelle l'équipe Go recevra des commentaires clairs et approuvés, cette dernière va procéder à l'implémentation pendant le cycle de développement de 3 mois (février, mars et avril 2019).

Source : Blog Go

Et vous ?

Utilisez-vous le langage Go ? Qu'en pensez-vous ?
A-t-il des chances de se faire une place parmi les langages les plus populaires ? Pourquoi ?
Que pensez-vous de l'approche de Google pour passer à Go 2 ?

Voir aussi :

Google annonce la sortie du runtime Go 1.11 sur App Engine, après la disponibilité de la nouvelle version de son langage
L'équipe de Go publie des brouillons du design du langage Go 2, au menu : la généricité, la gestion des erreurs et la sémantique des valeurs d'erreur
L'équipe en charge du développement de Go annonce la disponibilité de la version Go 1.11, qui s'accompagne d'un port expérimental pour WebAssembly
Go : après 5 ans de Go 1, la communauté du langage open source planifie une transition vers Go 2, en minimisant les perturbations entre les versions
Go est plus utilisé par les développeurs pour leurs projets personnels, selon le sondage Go 2016

[ant1ozie]

@codec_abc

Comme tu te plais a critiquer sans vraiment justifier tout ce qui bouge a propos de Go, je vais me permettre de te tutoyer. Et sans les accents, je suis ingenieur US.

J'ai l'impression que tu denigres beaucoup Go, donc pour te repondre:

- Go n'a pas ete cree par des amateurs en reponse a ce que tu as ecrit ici: "Je n'ai pas trop l'impression que les concepteurs de Go aient tant que ça d'expérience en création de langage de programmation. A contrario, Anders Hejlsberg après Delphi et C# il est passé sur...
"
Donc la, tu fais un peu de recherches, et tu peux decouvrir que tu as tout faux:
https://en.wikipedia.org/wiki/Rob_Pike
https://en.wikipedia.org/wiki/Ken_Thompson

Si tu ne sais pas lire l'anglais,
- Rob pike a ecrit/invente Plan9 - X server , UTF-8. personellement, le jour au j'aurai fait ne serait-ce que 10% de ses prouesses, je pourrait peut-etre me permettre de critiquer leur experience systeme.
- Ken a ecrit la version originale de UNIX. Il a aussi invente le language B qui a ete le precurseur de C. pareil, le mec, il a ecrit UNIX ET B quoi.. T'as ecrit quoi @codec_abc ? Julia? Haskell?

"C'est fantastique! Bientôt Go ressemblera à un langage de moitié du 20eme siècle.
J'ai franchement du mal à voir ce qui peut rendre attrayant Go. Ces créateurs ont clairement ignoré les décennies..."

Alors ca, c'est vraiment nul comme commentaire.
Tu peux avoir tes preferences, et promouvoir tel language et tel language...
Go est tres tres flexible, tu peux l'utiliser en language fonctionnel si tu decides de ne pas utiliser de pointeurs. Ou utiliser les boost (enormes) de performance en utilisant les pointeurs.
Moi perso, je n'aime pas Python, car j'ai l'impression de refaire du PhP. Je n'aime pas Java, ni C#, car les patterns objects rendent la logique plus complexe que ce qu'elle devrait etre. C'est une preference - cela ne veut pas dire que ce sont des language pourris.
C, ou C++, c'est le top - mais vas y les problemes et bugs d'allocation memoire, un truc simple comme les tableaux dynamiques......

Perso, si tu connaissais un minimum ton sujet, tu saurait que Go est un language du 21eme siecle, que niveau performance, C et C++ n'ont que l'avantage d'avoir des bindings Cuda.
Si tu connaissais un peu mieux ton sujet, tu verrais aussi que l'implementation des array est geniale, que le garbage collector fonctionne super bien, et que les go-routines sont SUPER lights et tres tres facile a implementer.
Aussi, Go est ecrit en Go. Donc si t'as envie de voir le source, un petit CMD+B, et je peut voir comment ils ont fait leur dispatcher de routines.
Leur systeme d'interface automatique est tres utile, et tres differente par rapport a des CLASS Generator Implements Interface et des GeneratorBuilder Implements A, implement B, implements C...

En fait, Go est anti OOP par design.

Si t'es un fan de OOP - ou alors que tu as l'habitude de programmer en OOP - Go pour sure va te destabiliser et peut te rendre haineux.

En fait, si je devais re-ecrire tous ce que j'ai ecris en Go en JAVA, C# ou C++, je pense que le volume de code va etre multiplie par au moins 5. Et les performances vont se degrader - car j'utilise enormement les go routines en parralelle.
Ce qui veut aussi dire que mes unit test vont exploser.

Un autre avantage qui fait de Go un language du 22ieme siecle, c'est le compilateur et C binding.

la je suis sur linux.

Je peux compiler mon programme Go pour Mac, Windows et Unix, rsync tout ca sur les serveurs ou machine clients.

je n'ai pas besoin d'installer des dependances - ou quoi que ce soit.

Les executables GO ne necessitent pas de libraries externes.

Donc , la j'ai 10.000 lignes de code Go qui utilisent des fonctionalitees et des libraries avancees.
Je CMD+B une fonction, cela m'ouvre directement le fichier source Go extern qui ne fait pas partie de mon projet.
Je n'ai pas besoin de faire de Make, ou de dependencie check lorsque je build.
je compile, les unit test passent, je check le PPROFF mem, CPU and RACE pour ameliorer les perf d'execution par 100.
Et BAM, j'ai un executable qui tourne PARTOUT sans rien d'autre.

Apres, si tu commences a utiliser des libraries externes, par exemple,
https://github.com/bobappleyard/readline qui bind sur une librarie C UNIX, donc ca te force l'installation de dependences a cote de ton systeme, ca devient un peu caduque.
mais en Fait, Go est TRES TRES populaire, et donc la plupart des libraries C on ete reecrite en Go: Donc a la place, vaut mieux utiliser: https://godoc.org/github.com/chzyer/readline. Et hop !
magie.

Pour moi, quand je fais

Code :

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

1
2
3
4
5
6
7
8
type MonObject struct {
    Name string
    name string
}
 
c := &MonObjet{}
d := MonObject{}
e := MonObject{name: "not exported"}

J'ai toutes les fonctionalitees necessaire dont j'ai besoin pour ecrire un programme complexe.

Ecrite la meme chose en JAVA par example prendrais probablement 3 fois plus de characteres.

Java n'est as pourri, c'est juste OOP.

Et desole pour les anglicismes. Mon clavier est us, et je pense et code en Anglais.
Et si tu n'as toujours pas compris, tu peux aller sur github et demander aux createur de Kubernetes, Docker, InfluxDB, Hugo, Etcd, Iris pourquoi ils ont chois Go, et tu peux aussi creer un ticket sur le code source de Go et demander aux createurs du language pourquoi ils n'ont pas implemente les generiques et fonction overloading.

Et il te repondra certainement que c'est pour les raisons suivantes: C'est des code smell. Cela veut dire que si tu utilise des nombres de parametres variables, c'est que ta logique est erronee au depart.

Et c'est pareil pour les Generiques, Si tu doit avoir des generique pour avoir du code re-utilisable, c'est du code smell. Erreur basique d'implementation.
Le generique a la limite pourrait etre utile pour feeder du contenu non structure (source NoSQL MongoDB par example) dans du code Go.
Mais voila les erreur nil pointer exception qui se pointent a l'horizons.

Enfin Bref, Go, c'est un language tres efficace, extremement moderne, stable et puissant.

Ils n'implementeront jamais les generiques, leur system d'erreur pue un peu.

Go ne merite pas tes critiques - surtout non fondees.

D'ailleur, vu que tu n'as jamais justifie tes critiques, je ne passerai pas ce que je viens d'ecrire dans un correcteur orthographique.

Monsieur, faite l'effort d'imaginer que mon code est bien meilleur que mon orthographe.