Discussion :

[Coriolan]

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

Go est un langage de programmation compilé et concurrent développé par Google. Les créateurs de Go ont voulu offrir aux développeurs, même ceux qui sont inexpérimentés, un langage facile à comprendre et facile à adopter pour réaliser de bons programmes. Depuis sa sortie en 2009, Go a connu une forte adoption à cause de ses avantages très intéressants, toutefois, des développeurs ont pointé du doigt certains de ses inconvénients.

En avril, le langage Go s’est doté d’un nouveau logo, une première étape dans la refonte de l’image du langage. Désormais, place à la conception de Go 2 annoncé l’année dernière. À l’occasion du sommet de contributeurs de Go qui se tient annuellement, les participants ont eu droit à un avant-goût des ébauches de possibles designs pour les changements à venir dans le langage. Dans le cadre de ce processus de design de Go 2, l’équipe de développement a publié ces brouillons afin de lancer le débat sur trois sujets : la généricité, la gestion des erreurs et la sémantique des valeurs d’erreur.

La gestion d’erreurs

L’effort autour de Go 2 a pour objectif global de se pencher sur les façons les plus significatives qui empêchent Go de garder son évolutivité à de larges bases de code et d’amples efforts de développeurs.

« Une façon qui fait que les programmes Go échouent à garder leur évolutivité réside dans l’écriture du code de vérification et de gestion d’erreurs, » a écrit Russ Cox, développeur de Google. « En général, les programmes de Go ont trop de code de vérification d’erreurs et pas assez pour s’en charger. L’ébauche du design vise à se pencher sur ce problème en introduisant une syntaxe allégée pour le contrôle d’erreur. »

Pour assurer l’évolutivité de larges bases de code, les programmes de Go doivent être légers sans répétition inutile, mais aussi robustes et gérant avec élégance les erreurs lorsqu’ils remontent en surface.

« Dans le design de Go, nous avons fait un choix conscient d’utiliser des résultats et des contrôles d’erreurs explicites. Par opposition, C typiquement utilise le contrôle explicite d’un résultat d’erreur implicite, errno, alors que la gestion d’exception, se trouvant dans beaucoup de langages comme C++, C#, Java et Python, représente un contrôle implicite de résultats implicites, » a écrit Cox.

« Les subtilités du contrôle implicite sont traitées dans « Cleaner, more elegant, and wrong » (2004), et « Cleaner, more elegant, and harder to recognize » (2005). En substance, parce que vous ne pouvez pas voir les contrôles implicites, il est difficile de vérifier par inspection que la gestion d’erreurs se recouvre de l’état du programme au moment où il y a un échec de contrôle. »

Cox a donné un exemple pour illustrer ce problème. On prend en considération ce code écrit en Go avec des exceptions :

Code :

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

1
2
3
4
5
6
7
8
func CopyFile(src, dst string) throws error {
    r := os.Open(src)
    defer r.Close()
 
    w := os.Create(dst)
    io.Copy(w, r)
    w.Close()
}

Ce code est élégant et propre, mais aussi invisiblement erroné : si io.copy ou w.Close échouent, le code ne supprime pas le fichier dst écrit partiellement.

D’autre part, l’équivalent de ce code aujourd’hui est :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return err
    }
    defer r.Close()
 
    w, err := os.Create(dst)
    if err != nil {
        return err
    }
    defer w.Close()
 
    if _, err := io.Copy(w, r); err != nil {
        return err
    }
    if err := w.Close(); err != nil {
        return err
    }
}

Ce code n’est ni élégant ni propre et il est toujours faux comme la version précédente, il ne supprime pas le fichier dst quand io.Copy ou w.Close échouent. Il y a un argument plausible qu’un contrôle visible puisse pousser un lecteur attentif à se demander quelle réponse de contrôle d’erreur est appropriée à ce point du code. En pratique, cependant, les contrôles d’erreur prennent trop d’espace que les lecteurs apprennent rapidement à les ignorer pour voir la structure du code.

Le code a aussi une seconde omission dans son contrôle des erreurs. Les fonctions doivent inclure typiquement des informations pertinentes sur leurs arguments dans leurs erreurs, comme os.Open qui retourne le nom du fichier ouvert. Retourner l’erreur non modifiée produit un échec sans aucune information sur la séquence d’opération qui a conduit à cette erreur.

Pour résumer, ce code inclut beaucoup trop de vérifications d’erreur et pas assez de contrôle. Une version plus robuste avec plus d’erreurs utiles serait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()
 
    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
 
    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
 
    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Corriger ces fautes n’a fait que rendre le code plus correct, pas plus propre ou plus élégant.

Valeurs d'erreur et programmation générique

De ce fait, Cox note que Go 2 vise à rendre le contrôle d’erreurs plus léger, en réduisant la quantité du texte dans le programme Go dédié à la vérification d’erreurs. Il y a aussi l’envie de rendre l’écriture de gestion d’erreurs plus pratique, ce qui augmente la chance que les programmeurs vont allouer du temps à le faire. Tout ça sans mentionner le fait que la vérification et le contrôle d’erreurs doit rester explicite, donc explicite dans le texte du programme.

En plus de la gestion d’erreur, l’équipe veut faire en sorte que les programmes larges doivent être en mesure de tester et réagir aux erreurs et aussi les rapporter d’une bonne façon.

« Une façon qui fait que les programmes en Go échouent à bien garder leur évolutivité réside dans la capacité d’erreurs typiques. Une variété de paquets populaires ajoute des fonctionnalités qui vont au-delà de l’interface d’erreur standard, mais dans des façons incompatibles, » a écrit Cox. « Avec Go 2, nous envisageons de standardiser des “interfaces optionnelles” pour des erreurs afin de permettre aux paquets d’interopérer et idéalement en réduire le besoin. »

Pour faire cela, Cox a cité deux objectifs qui correspondent à ces problèmes : d’abord, il y a un besoin de rendre l’inspection par programmes plus facile et moins exposée aux erreurs, le but étant d'améliorer le contrôle d’erreurs et la robustesse des programmes réels. Deuxièmement, l’équipe veut rendre possible l’impression d’erreurs avec des détails additionnels dans une forme standard.

Enfin, l’équipe a parlé de la programmation générique et comment elle compte l’implémenter dans Go. En programmation, la généricité (ou programmation générique), consiste à définir des algorithmes identiques opérant sur des données de types différents. On définit de cette façon des procédures ou des types entiers génériques. On pourrait ainsi programmer une pile, ou une procédure qui prend l'élément supérieur de la pile, indépendamment du type de données contenues.

Cox note que l’équipe est consciente du potentiel de la généricité, pour rendre Go plus flexible et puissant et en même temps loin d’être plus compliqué. En gros, l’équipe veut rendre possible le polymorphisme paramétrique avec des paramètres de type. Mais cette implémentation va se faire à petits pas histoire d’apprendre et éviter les problèmes que la généricité a causés dans C++ et Java.

Pour consulter en détail ces brouillons, veuillez consulter les documents publiés par l’équipe de Go.

Source : googlesource

Et vous ?

Qu’en pensez-vous ?
Utilisez-vous le langage Go ? Quels sont les avantages que vous lui trouvez ?
Et quels sont ses inconvénients ?

Voir aussi

Le langage Go se dote d'un nouveau logo, une première étape dans la refonte de l'image du langage, la mise à jour du site sera la prochaine étape
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 langage Go se mesure à C++, Java et Scala une nouvelle étude comparative des performances, menée par un ingénieur de Google

[codec_abc]

C'est fantastique! Bientôt Go ressemblera à un langage de moitié du 20ieme siècle.

J'ai franchement du mal à voir ce qui peut rendre attrayant Go. Ces créateurs ont clairement ignoré les décennies de recherches que des chercheurs ont fait sur les langages et implémentation et on se retrouve avec un langage primitif et hyper verbeux. A ma connaissance seul le tooling est plutôt bien foutu (encore que j'ai entendu que la gestion de dépendances est un peu laxiste). Bon en même temps, c'était annoncé dès le début par Rob Pike:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Du coup, je me demande si les gens qui apprécient Go:

1- Sont d'accord avec la phrase ci-dessus ?
2- Se considère eux-mêmes comme étant incapable de comprendre un langage brillant ?

Si un gopher qui passe par là veut bien répondre à ces questions je le remercie par avance.

[Mingolito]

En fait Go c'est quoi ? C'est un reboot marketing par Google du Pascal Objet mais en moins bien ?

[pboulanger]

Vive le C ou le C++... "Go' too null...

[strato35]

Sur le papier c'est bien joli le Go.. mais bon la structure du code est quand même moche... Quand on viens d'autres langages "courant" comme le C# ou le Java, ça donne juste la gerbe de voir ce genre de code...
Après je suis pas contre la volonté de faire un langage accessible, mais ça veux dire que quelqu'un débutant par du Go aura beaucoup de mal à passer vers un langage historique le jour où il en aura besoin, et un habitué des autres va râler comme un Javaiste qui se met au php... (Je n'ai rien contre java ou php, je pratique les 2, et je râle sur les 2...)

Vive le C ou le C++... "Go' too null...

Ce n'est pas dans la même cours.. tu admettra tout de même qu'il est plus facile de faire du python pour "monsieur tout le monde" que de faire du C++ ... (même si on est d'accord, C++ ça déchire quand on sais l'utiliser )

Si un gopher qui passe par là veut bien répondre à ces questions je le remercie par avance

+1

[Dymmm]

Si un gopher qui passe par là veut bien répondre à ces questions je le remercie par avance.

Bon, je suis sur pas un gopher pur et dur, mais j'ai néanmoins sélectionné ce langage pour mon prochain projet back-end de mon département. Je travail dans une mini équipe de deux personnes et nous sommes en charge de la création, évolution et de la maintenance d'un backend mode SOA. Habituellement mon département travail en C et cela depuis 1985. J'ajouterai même que, à mon grand regret et malgré mes efforts, notre processus de développement est issu de cette année également.

Par rapport au C, utiliser le Go permet, jusqu’à présent, de régler pas mal de souci :

• source bien plus facile a lire que le C
• Dispose d’une bibliothèque standard importante
• la gestion des erreurs et bien plus naturelle : si ca retourne un 'error' alors il faut le gérer
• conversion implicite causant des effets de bord pénible a localiser
• plus de dead lock
• fuite de mémoire courante lors des premières releases en prod
• liaison statique des bibliothèque, donc plus de version de bibliothèque a installer en prod

Alors comme ça, on peut dire que le C l'offre aussi... mais, cela dépend avec qui on travail. Le Go sera moins permissif que le C et permettra d'obtenir cela plus naturellement. Les mentalités de certaines personnes sont dures à changer et dans ce cas, j'ai grand espoir que le Go améliorera grandement la qualité logicielle.

[SofEvans]

Par rapport au C, utiliser le Go permet, jusqu’à présent, de régler pas mal de souci :

• source bien plus facile a lire que le C
• Dispose d’une bibliothèque standard importante
• la gestion des erreurs et bien plus naturelle : si ca retourne un 'error' alors il faut le gérer
• conversion implicite causant des effets de bord pénible a localiser
• plus de dead lock
• fuite de mémoire courante lors des premières releases en prod
• liaison statique des bibliothèque, donc plus de version de bibliothèque a installer en prod

Je suis dans le même cas que toi : Je fais du C et on est en cours de migration Go.

Autant sur certains point je suis d'accord, sur d'autre je sais pas, et sur le reste, je ne suis pas d'accord.

Dire que lier statiquement les bibliothèques en Go c'est mieux que le C, c'est juste passer à côté des points suivant :
* le C te permets de lier une bibliothèque en statique ou dynamique
* Si on fait des bibliothèques dynamique et statique, c'est bien que chacune possède des avantages et des inconvénient.
En l'occurence, si tu ne fais que du statique, le jour où tu découvre un bug dans une bibliothèque, t'es bon pour recompiler tout tes projets et tous les redéployer (avec tout le bazar que ça engendre).
* Go l'a très bien compris, et propose maintenant de faire des bibliothèque dynamique (même utilisable en C ! On va utiliser cet aspect pour faire une migration "en douceur").


Pour les fuite de mémoire en C, il faut rajouter une étape "valgrind/Dr Memory" à votre chaîne de test (même si je suis d'accord qu'avec certaines bibliothèque on obtient des faux positif : merci libssl).

Pour la gestion de l'erreur, je suis surpris. Je ne savais qu'il fallait absolument gérer les erreurs en Go. Y'a pas moyen de les ignorer ?

[Pyramidev]

Dymmm et SofEvans, pourquoi avoir choisi Go au lieu de Rust ? Est-ce à cause des bibliothèques ou bien d'autre chose ?

[SofEvans]

Décision hiérarchique, et je n'ai pas les connaissances nécessaires en Go ou Rust pour y dire quoi que ce soit.

[Dymmm]

Dymmm et SofEvans, pourquoi avoir choisi Go au lieu de Rust ? Est-ce à cause des bibliothèques ou bien d'autre chose ?

Dans mon cas, mon choix a été orienté par des considérations psychologiques. je dois m'assurer que le langage choisi soit accepté par mes collègues. J'ai choisi le Go car il est simple et relativement proche du Pascal, langage regretté par certaines des personnes avec qui je travail. Le Rust me plait bien, mais il offre bien trop de choses effrayantes, POO et autre. J'ai vu passer des choses effarantes écrites en C... je n'ose pas imaginer ce qui pourrait être produit en Rust

Je suis dans le même cas que toi : Je fais du C et on est en cours de migration Go.

Autant sur certains point je suis d'accord, sur d'autre je sais pas, et sur le reste, je ne suis pas d'accord.

Dire que lier statiquement les bibliothèques en Go c'est mieux que le C, c'est juste passer à côté des points suivant :
* le C te permets de lier une bibliothèque en statique ou dynamique
* Si on fait des bibliothèques dynamique et statique, c'est bien que chacune possède des avantages et des inconvénient.
En l'occurence, si tu ne fais que du statique, le jour où tu découvre un bug dans une bibliothèque, t'es bon pour recompiler tout tes projets et tous les redéployer (avec tout le bazar que ça engendre).
* Go l'a très bien compris, et propose maintenant de faire des bibliothèque dynamique (même utilisable en C ! On va utiliser cet aspect pour faire une migration "en douceur").


Pour les fuite de mémoire en C, il faut rajouter une étape "valgrind/Dr Memory" à votre chaîne de test (même si je suis d'accord qu'avec certaines bibliothèque on obtient des faux positif : merci libssl).

Pour la gestion de l'erreur, je suis surpris. Je ne savais qu'il fallait absolument gérer les erreurs en Go. Y'a pas moyen de les ignorer ?

Bon, c'est vrai que tu n'avais pas toutes les info en mains. Actuellement, nous travaillons sur des AIX avec "vi" et "xlc" en SSH. J'ai essayer durant un temps de travailler en parallele sur Linux pour assurer un minimum de test avec Valgind mais cela c'est avéré trop chronophage et je n'arrivais pas a justifier les modifications pour compatibilité big - little endian.
En ce qui concerne les liaisons dynamiques, lorsque les serveurs de dev, certification et prod n'ont jamais les mêmes versions des lib les catastrophes arrivent.

[codec_abc]

Bon, je suis sur pas un gopher pur et dur, mais j'ai néanmoins sélectionné ce langage pour mon prochain projet back-end de mon département. Je travail dans une mini équipe de deux personnes et nous sommes en charge de la création, évolution et de la maintenance d'un backend mode SOA. Habituellement mon département travail en C et cela depuis 1985. J'ajouterai même que, à mon grand regret et malgré mes efforts, notre processus de développement est issu de cette année également.

Par rapport au C, utiliser le Go permet, jusqu’à présent, de régler pas mal de souci :

• source bien plus facile a lire que le C
• Dispose d’une bibliothèque standard importante
• la gestion des erreurs et bien plus naturelle : si ca retourne un 'error' alors il faut le gérer
• conversion implicite causant des effets de bord pénible a localiser
• plus de dead lock
• fuite de mémoire courante lors des premières releases en prod
• liaison statique des bibliothèque, donc plus de version de bibliothèque a installer en prod

Alors comme ça, on peut dire que le C l'offre aussi... mais, cela dépend avec qui on travail. Le Go sera moins permissif que le C et permettra d'obtenir cela plus naturellement. Les mentalités de certaines personnes sont dures à changer et dans ce cas, j'ai grand espoir que le Go améliorera grandement la qualité logicielle.

Déjà il y a quelques erreurs dans ta liste de features:

• Des dead locks peuvent arriver en Go (et aussi des dataraces)
• Ce n'est pas parce que Go est garbage collecté que les memory leaks n'existent plus. Comme dans tous les langages garbage collecté elles sont plus dur à produire mais loin d'être impossible.

Ensuite il y a débat sur la gestion d'erreurs, bien qu'elle soit "complète" (chose que j'apprécie de manière générale), elle est hyper verbeuse et des langages comme Rust pourtant plus bas niveau font beaucoup mieux. Et je ne parle de ce passage sur la FAQ qui est juste pitoyable.

Et après, pour la très grande majorité des points que tu cites, des langages "battle tested" tel que Java ou C# les fournissent avec un écosystème (et un pool de développeur) bien plus grand que celui de Go. Du coup, je suis toujours pas convaincu par ce que Go apporte. Ça me donne l'impression que Go c'est pour les dinosaures qui ne veulent pas apprendre un langage plus récent dans les domaines ou le C ne se justifie plus aujourd'hui.

[SofEvans]

Bon, c'est vrai que tu n'avais pas toutes les info en mains. Actuellement, nous travaillons sur des AIX avec "vi" et "xlc" en SSH. J'ai essayer durant un temps de travailler en parallele sur Linux pour assurer un minimum de test avec Valgind mais cela c'est avéré trop chronophage et je n'arrivais pas a justifier les modifications pour compatibilité big - little endian.

Ah ouais ... Mes condoléances alors.
Je fais des programmes pas trop gros, et je suis très méthodique surtout concernant l'allocation dynamique, alors j'ai pas souvent des fuites de mémoire (et je m'en aperçois quand je fais les tests en DEV, en général). Mais j'ai quand même la chance de pouvoir faire un coup de valgrind quand il le faut.

En ce qui concerne les liaisons dynamiques, lorsque les serveurs de dev, certification et prod n'ont jamais les mêmes versions des lib les catastrophes arrivent.

Oui, ca c'est sûr. De notre côté, on traite les bibliothèques comme n'importe quel autre binaires : dev -> preprod -> prod, et on ne s'interrompt pas dans le chaînage, donc ça nous arrive rarement d'avoir des bug parce que la lib de preprod (ou pire, prod) n'est pas celle attendue.
Par contre, quand ça arrive, c'est vrai que c'est ultra rageant de perdre du temps.

[Pyramidev]

Ces créateurs ont clairement ignoré les décennies de recherches que des chercheurs ont fait sur les langages et implémentation et on se retrouve avec un langage primitif et hyper verbeux. A ma connaissance seul le tooling est plutôt bien foutu (encore que j'ai entendu que la gestion de dépendances est un peu laxiste). Bon en même temps, c'était annoncé dès le début par Rob Pike:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

D'ailleurs, même quand on conçoit un langage qui cible prioritairement les débutants, il y a quand même besoin d'avoir une bonne culture générale sur l'état de l'art dans la conception de langages de programmation.

Par exemple, le fait que les adresses valides et les adresses optionnelles aient le même type facilite les erreurs. En 2009, Tony Hoare a nommé cette erreur de conception son « erreur à un milliard de dollars » :
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Go est sorti en 2009, mais le problème était déjà connu avant. En C, ce problème facilite l'écriture de code qui crash. En Java, cela facilite l'écriture de code qui lance des NullPointerException. Pour pallier cette faiblesse dans le typage, on peut essayer de mettre en place des conventions, par exemple en disant qu'aucun pointeur ne peut être nul sauf mention explicite du contraire, mais le risque persistera car ces conventions ne seront pas universelles.

Ce problème de conception est résolu, par exemple dans des langages comme Haskell (sorti bien avant Go) et Rust (sorti après) qui utilisent bien des types différents pour distinguer ce qui est optionnel de ce qui ne l'est pas : voir Maybe en Haskell et Option en Rust.

Les concepteurs du langage Go, par contre, ont sauté à pieds joints sur cette erreur de conception. Pour empirer les choses, dans A Tour of Go, j'ai lu : in Go it is common to write methods that gracefully handle being called with a nil receiver. (lien)

[LLB]

J'ai utilisé Go au travail, je le trouve assez agréable.

Go est un langage simple et pragmatique. On ne trouve pas autant de fonctionnalités que dans Haskell ou Scala; il utilise un nombre assez limité de concepts. Ce n'est pas le langage le plus fun à apprendre ou à utiliser. Mais c'est un langage simple à apprendre : on est rapidement productif. Je connais des gens qui ont essayé de coder la même chose en Go et en Rust. Au bout d'une semaine, ils avaient encore du mal avec des concepts de Rust, alors qu'ils étaient productifs en Go dès le premier jour (pour Go, c'était aussi mon expérience quand j'ai commencé en 2012).

J'aime bien Go, parce que je comprends rapidement le code des autres - plus que dans les autres langages que j'ai utilisés par le passé. Par sa simplicité, Go force les gens à faire les choses de la même façon. Tout le monde suit les mêmes conventions, la même indentation (via gofmt), place les accolades au même endroit (c'est imposé), gère les erreurs de la même façon (on a assez peu de choix), etc. En ce sens, Go est un bon langage quand on travaille en équipe, sur une base de code potentiellement grosse. La compilation est rapide, ce qui est très important aussi.

Il est aussi agréable à utiliser pour du code parallèle. Et j'aime bien les interfaces à la place de la POO (et de l'héritage).

À mon sens, les principaux problèmes sont la gestion d'erreur trop verbeuse, le manque de generics et les null pointer exceptions. Go 2 devrait corriger les deux premiers problèmes. On verra ce que ça donnera.

[Fabiende]

J'ai franchement du mal à voir ce qui peut rendre attrayant Go. Ces créateurs ont clairement ignoré les décennies de recherches que des chercheurs ont fait sur les langages et implémentation et on se retrouve avec un langage primitif et hyper verbeux. A ma connaissance seul le tooling est plutôt bien foutu (encore que j'ai entendu que la gestion de dépendances est un peu laxiste). Bon en même temps, c'était annoncé dès le début par Rob Pike:


Du coup, je me demande si les gens qui apprécient Go:

1- Sont d'accord avec la phrase ci-dessus ?
2- Se considère eux-mêmes comme étant incapable de comprendre un langage brillant ?

Si un gopher qui passe par là veut bien répondre à ces questions je le remercie par avance.

Je programme depuis 30 ans, j'enseigne l'informatique depuis plus de 15 ans, et des langages, j'en ai pratiqué pas mal, donc je suis loin de me considérer comme un débutant. Pourtant ça fait 5 ans que je me suis mis à go, et c'est maintenant mon ménage de choix, sauf contrainte extérieure.

Pourquoi ? Parce que c'est un langage simple et ennuyeux, justement. Parce que je sais que je suis capable de comprendre n'importe quel code, le mien d'il y a un an ou celui de quelqu'un d'autre, sans avoir à me demander "mais pourquoi il a fait ça ?" Ou "mais ça veut dire quoi cette syntaxe dans ce contexte ?". Ça veut aussi dire que, si j'ai besoin d'un développeur qui ne connait pas le langage que j'utilise, il pourra l'apprendre en quelques jours et être productif au bout d'une semaine.

Ça, et, dans une moindre mesure, la facilité de déploiement. En une ligne, je peux compiler et déployer mon code sur une machine distante, avec une architecture différente, dans rien avoir besoin d'installer sur la machine cible.

[Pyramidev]

En gros, Go, c'est le rêve de la plupart des entreprises. Les développeurs seront encore plus facilement interchangeables qu'avant, car le langage ne sera plus un obstacle, surtout pour recruter des jeunes pas chers.

Il existe plein de qualités avec lesquelles un langage peut rendre des développeurs plus productifs :

• Un langage concis permet d'écrire plus facilement du code auto-documenté. Si on connaît la syntaxe du langage, alors on relit plus vite le code et on comprend plus vite son fonctionnement.
• Un langage avec de puissants outils d'abstraction permet de mieux respecter DRY (Don't Repeat Yourself), ce qui permet d'écrire du code plus robuste. Dans ce domaine, le paradigme le plus puissant est la métaprogrammation.
• Un langage qui permet de faciliter un style fonctionnel dans lequel la majorité des fonctions sont déterministes et sans effet de bord (idéalement avec une garantie à la compilation) permet d'écrire du code facile à tester et dont les dépendances sont explicites.
• Un langage qui fait beaucoup de contrôles à la compilation permet de repérer plus tôt certaines étourderies.
• Un langage qui facilite la génération de code machine performant évite d'obliger de faire de sales bidouilles dans le code (par exemple sacrifier l'abstraction) pour augmenter la vitesse d'exécution.

Mais, plus on essaye d'avoir ce genre de qualité dans un langage, plus il est difficile de concevoir un langage facile à apprendre. Alors, hop, on sacrifie tout ça. De toute façon, la plupart des jeunes recrues pas chères ne sauraient pas coder correctement dans un langage trop technique.

Comment ? Vous êtes développeur Go et vous désirez une augmentation de salaire ? Pourquoi auriez-vous une augmentation alors que vous écrivez le même genre de code que notre stagiaire Kevin ?

Je caricature, car le rôle d'un développeur ne se limite pas à écrire du code. Mais c'est quand même un rôle important.

À part ça, les langages les plus utilisés en entreprise ne sont pas super balèzes non plus. Mais je souhaite que ça évolue dans le bon sens : expressivité, abstraction, contrôles, performances, etc. Être facile à apprendre est un bon point, mais il ne faut pas que ce soit trop au détriment de tout le reste.

[codec_abc]

Pourquoi ? Parce que c'est un langage simple et ennuyeux, justement. Parce que je sais que je suis capable de comprendre n'importe quel code, le mien d'il y a un an ou celui de quelqu'un d'autre, sans avoir à me demander "mais pourquoi il a fait ça ?" Ou "mais ça veut dire quoi cette syntaxe dans ce contexte ?"

Dans ton cas aucun langage ne répondra à la question "Pourquoi il a fait ça" (normalement ce sont les commentaires qui expliquent ça si ce n'est pas évident). Généralement en programmation le problème que l'on cherche à résoudre est plus compliqué que le code qui est écrit (pour un peu que tu écrives quelques chose d'un plus complexe qu'une simple app CRUD). Si ce qui bloque tes développeurs c'est la syntaxe d'un langage (hormis les cas extrême que l'on peut trouver dans le C++ et assimilé) alors c'est mauvais signe, c'est probablement qu'ils sont incapable d'apprendre une syntaxe un peu différente et/ou incapable d'utiliser Google. Et ces 2 qualités sont quand mêmes celles typiques d'un bon dev (ou du moins on les trouve pas chez les mauvais devs). Aussi la simplicité apparente de Go ça mène à ce genre de folie qui est bien pire que les concepts qu'ils refusent d'utiliser de par leur "complexité".

[LLB]

Un projet peut avoir une longue durée de vie. Il peut y avoir beaucoup de contributeurs, il peut y avoir beaucoup de fichiers. Comme on l'a dit, la facilité à lire, comprendre et maintenir le code est un avantage énorme. Bien sûr, ce n'est pas le seul critère à prendre en compte. Les langages de programmation doivent avant tout faire des compromis (aucun langage n'est parfait).

Un système de typage plus puissant peut venir avec d'autres contraintes : difficultés à écrire les types, ou messages d'erreur durs à déchiffrer, ou inférence de type dure à prévoir, ou contraintes sur le langage, ou temps de compilation plus longs. C'est un compromis à faire.

Pour critiquer un langage, il faut d'abord comprendre quels compromis ont fait les développeurs et quelles étaient leurs priorités. Si tes priorités personnelles ne correspondent pas à celles des créateurs de Go, alors tu voudras probablement utiliser un autre langage.

Rob Pike a écrit il y a quelques jours : "I claim that software engineering is the double integral of programming over time and people. What makes the difference between programming and engineering is what makes a program survive over time in an evolving ecosystem while being maintained by a changing population."
C'est dans ce contexte que Go est intéressant (mais pas que !). Si tu veux mieux comprendre leur vision, j'ai trouvé intéressants l'article Less is More et la présentation Simplicity is Complicated (ou juste les slides).

Si ce qui bloque tes développeurs c'est la syntaxe d'un langage

Non, la syntaxe n'est souvent qu'un détail. Il faut aussi idéalement comprendre l'ensemble des fonctionnalités du langage et comment elles interagissent entre elles, avant de choisir comment écrire le code. Plus le langage est complexe, plus c'est dur de choisir et plus il y a de risques de ne pas faire les choses correctement. Peut-être un développeur utilisera les classes d'OCaml, l'introspection de Python, les templates de C++ ou les macros de C d'une façon qu'il croit intelligente. Mais ça peut aussi piéger le prochain développeur qui modifiera le code. Même s'il n'y a que des gens compétents, c'est dur de garantir que personne ne fera d'erreur.

Même après avoir utilisé OCaml en entreprise pendant des années, après avoir travaillé avec Don Syme sur F# pendant deux ans, et utilisé plein d'autres langages, je trouve que Go a un avantage : lire et maintenir du code existant est plus simple avec Go. Les autres langages ont leurs avantages, ce n'est qu'une question de compromis (oui, le code en F#, Scala ou Haskell est plus fun à écrire et ils ont des systèmes de typage plus intéressants).

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.

[Fabiende]

Dans ton cas aucun langage ne répondra à la question "Pourquoi il a fait ça" (normalement ce sont les commentaires qui expliquent ça si ce n'est pas évident). Généralement en programmation le problème que l'on cherche à résoudre est plus compliqué que le code qui est écrit (pour un peu que tu écrives quelques chose d'un plus complexe qu'une simple app CRUD). Si ce qui bloque tes développeurs c'est la syntaxe d'un langage (hormis les cas extrême que l'on peut trouver dans le C++ et assimilé) alors c'est mauvais signe

Je ne parle pas d'une syntaxe qui me ferait "bloquer", mais qui m'obligerait à m'arrêter pour réfléchir. Quand tu lis du code, il se passe deux choses en même temps : d'une part, tu dois comprendre ce que ce bout de code veut dire, ce qu'il fait concrètement, et d'autre part tu dois comprendre en quoi ça résout le problème (et comme tu le dis, en général ça n'est pas trivial). Un aspect local et un aspect global. Et le problème, c'est que c'est difficile de mener les deux activités de front, donc quand tu rencontres une construction syntaxique ou une manière de faire dont tu n'as pas l'habitude, tu es obligé de passer du temps à comprendre ce qui se passe concrètement, avant de savoir si tu peux modifier telle ou telle portion de code, et après seulement tu peux te replonger dans la compréhension globale du code.

Et pas besoin d'être mauvais développeur pour rencontrer une construction inhabituelle ou alambiquée, même dans un langage qu'on maîtrise. Quand Java 8 est sorti avec les lambdas, j'ai vu des développeurs se lâcher et écrire sous forme purement fonctionnelle des expressions complexes pour implémenter l'équivalent d'une double boucle. Je n'ai rien contre les écritures fonctionnelles, loin de là, et j'arrive à comprendre une écriture fonctionnelle, mais là le code était tellement inhabituel qu'il m'a fallu prendre le temps d'analyser l'expression, de la "tester" à la main, pour vérifier qu'elle faisait bien ce que je pensais, et le temps que j'ai passé à ça, je ne l'ai pas passé à autre chose. Ce n'est qu'un exemple parmi tant d'autres, évidemment (C++ étant effectivement le pire, de ce point de vue).

Aussi la simplicité apparente de Go ça mène à ce genre de folie qui est bien pire que les concepts qu'ils refusent d'utiliser de par leur "complexité".

Ça c'est bien vrai, il n'y a pas de miracle, si l'on sort la complexité du langage, elle rejaillit quelque part dans le code en lui-même. Il n'y a pas de solution parfaite, uniquement des compromis.

[pboulanger]

Personnellement si le Go doit être utilisé car les développeurs sont incapables de travailler avec du C ou C++, eh ben passons les sous Python....
Le souci, à force de trop simplifier les langages ou les outils, les développeurs n'ont plus conscience de la complexité ou de la gestion de la mémoire et on arrive à des hérésies... Combien de fois ai-je dû intervenir sur des projets ou le développeurs avait codé sans prendre conscience de ce qu'ils faisaient ou du contexte dans lequel il le faisait?
Je me souviens d'un cas où avec 100000 lignes en base on mettait 3h, avec 200000 on mettait 17h et après une semaine de travail à 2 on est passé à 3mn pour 200000 lignes...