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 !

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

Le , par Michael Guilloux

390PARTAGES

16  0 
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

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

Avatar de ant1ozie
Nouveau Candidat au Club https://www.developpez.com
Le 21/01/2019 à 20:40
@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
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.
1  3