FAQ GoConsultez toutes les FAQ

[Traduction de la FAQ officielle]

Il était important pour nous d'étendre l'espace des identifiants au-delà des limites de l'ASCII. La règle édictée par Go – les caractères des identifiants doivent être des lettres ou des chiffres tels que les définit Unicode – est simple à comprendre et à mettre en œuvre, mais souffre cependant de restrictions. Par exemple, il n'est pas possible d'utiliser des caractères composés. Tant qu'il n'existe pas de règle externe communément admise sur ce que peut être un identifiant, ainsi qu'une définition canonique des identifiants garantissant qu'il n'y a pas d'ambiguïté, il a paru préférable de se passer des caractères composés. Nous avons ainsi une règle simple qui pourra être étendue ultérieurement sans casser les programmes existants et qui évite des bogues qui surviendraient inévitablement avec une règle autorisant les identifiants ambigus.
Dans le même ordre d'idées, comme un identifiant exporté doit commencer par une lettre capitale, les identifiants à partir des « lettres » de certaines langues ne peuvent, par définition, être exportés. Pour le moment, la seule solution est d'utiliser quelque chose comme X日本語, ce qui n'est manifestement pas très satisfaisant ; nous étudions d'autres solutions. Mais il est peu probable que la règle voulant que la casse (lettre initiale capitale ou minuscule) gouverne la visibilité de l'identifiant soit abandonnée ; c'est l'une des caractéristiques de Go que nous aimons le plus.

[Traduction de la FAQ officielle]

Chaque langage possède des fonctionnalités nouvelles et omet la fonctionnalité favorite de tel ou tel programmeur. Go a été conçu avec des objectifs tels que le plaisir de programmer, la vitesse de compilation, l'orthogonalité des concepts et la nécessité de supporter le parallélisme et la gestion de la mémoire par un système ramasse-miettes (garbage collection). Il se peut que votre fonctionnalité favorite soit absente parce qu'elle serait contraire à ces objectifs, parce qu'elle affecterait la vitesse de compilation ou la clarté de conception, ou parce qu'elle rendrait trop complexe le modèle de base du système.
Si vous trouvez gênant que la fonctionnalité X soit absente, veuillez nous pardonner et vous renseigner sur les fonctionnalités que possède Go. Vous ne trouverez peut-être que celles-ci.

[Traduction de la FAQ officielle]

Les types génériques sont pratiques, mais ils impliquent un coût en terme de complexité du système de types et de durée d'exécution. Nous n'avons pas trouvé pour l'instant de mécanisme susceptible de créer une valeur proportionnelle à la complexité, même si nous continuons à y réfléchir. En même temps, les maps et les tranches de Go, ainsi que la possibilité d'utiliser une interface vide pour construire des conteneurs, en utilisant un « déballage » (unboxing, c'est-à-dire obtenir la valeur d'un objet à l'aide d'une simple conversion de type) explicite, font qu'il est bien souvent possible d'écrire du code générique, même si c'est moins pratique.

La question reste ouverte.

[Traduction de la FAQ officielle]

Nous pensons qu'associer des exceptions à une structure de contrôle, du style try-catch-finally, conduit à du code inutilement compliqué. Cela tend aussi à encourager les programmeurs à qualifier d'exceptionnelles trop d'erreurs ordinaires, comme l'impossibilité d'ouvrir un fichier.
Go adopte une démarche différente. Pour la gestion des erreurs, la possibilité de renvoyer plusieurs valeurs fait qu'il est possible de rapporter une erreur sans surcharger la valeur de retour. Le type canonique error, combiné à d'autres fonctionnalités de Go, rend la gestion des erreurs agréable, mais assez différente de ce qui se fait dans d'autres langages.
Go possède aussi quelques fonctions internes pour signaler une situation exceptionnelle et y remédier. Le mécanisme de reprise n'est exécuté que quand une fonction est en état d'erreur, ce qui suffit à gérer la catastrophe sans nécessiter de structure de contrôle supplémentaire. Bien utiliser, cela donne un code de gestion d'erreurs propre et clair.
Consultez l'article Defer, Panic, AetMD Recover pour des détails complémentaires.

[Traduction de la FAQ officielle]

Go ne fournit pas d'assertions. Il est indéniable que les assertions sont un mécanisme pratique, mais notre expérience nous dit que les programmeurs ont tendance à les utiliser comme une béquille pour éviter d'avoir à écrire du code adéquat pour gérer et signaler les erreurs. Un mécanisme de gestion d'erreur adéquat signifie qu'un serveur continue à fonctionner après une erreur non fatale. Un mécanisme de signalement d'erreur adéquat implique que les erreurs sont clairement identifiées et épargnent au programmeur de devoir interpréter un fichier de trace d'erreur gigantesque. Une description précise des erreurs est particulièrement importante quand le développeur voyant l'erreur n'est pas familier avec le code.
Nous comprenons que c'est un point litigieux. Il y a un bon nombre de choses dans le langage et les bibliothèques Go qui diffèrent de certaines pratiques modernes, mais c'est tout simplement parce que nous pensons qu'il est parfois préférable d'essayer une démarche différente.

[Traduction de la FAQ officielle]

La programmation de processus parallèles ou de processus légers (multithreading) est notoirement difficile. Nous pensons que c'est dû en partie à des conceptions complexes comme les pthreads, et en partie au besoin d'utiliser des mécanismes de bas niveau comme les mutex, les variables conditionnelles et les barrières mémoires. Des interfaces de plus haut niveau permettent d'écrire du code bien plus simple, même s'il existe encore des mutex et pièces du même genre sous le capot.

L'un des meilleurs modèles de support de haut niveau pour le parallélisme est issu des Processus Séquentiels Communicants (CSP) de Tony Hoare. Occam et Erlang sont deux langages connus pour en dériver. Les primitives de parallélisme de Go dérivent d'une autre branche de cet arbre généalogique dont la principale contribution est la puissante notion de canal en tant qu'objet de première classe. L'expérience obtenue de plusieurs autres langages antérieurs a montré que le modèle CSP fonctionne bien dans un modèle de langage procédural.

[Traduction de la FAQ officielle]

Les goroutines contribuent à rendre le multitâche facile à utiliser. L'idée, qui est présente dans les esprits depuis un moment, est de multiplexer des fonctions s'exécutant de façon indépendante – des coroutines – sur un ensemble de threads. Quand une coroutine se bloque, par exemple à la suite d'un appel système bloquant, l'environnement d'exécution (runtime) du programme déplace les autres coroutines s'exécutant sur le même thread vers un autre thread non bloqué. Le programmeur n'en sait rien, ce qui est le but recherché. Le résultat, que nous appelons des goroutines, est peu gourmand en ressources : les goroutines ont un surcoût faible au-delà de la pile, qui représente seulement quelques kilooctets.
Pour que les piles soient petites, l'environnement d'exécution utilise des piles limitées pouvant être étendues. Une goroutine qui vient d'être créée ne reçoit que quelques kilooctets, ce qui est presque toujours suffisant. Quand ce n'est pas suffisant, l'environnement d'exécution alloue de la mémoire supplémentaire pour cette pile (et en reprend le cas échéant). Ce mécanisme permet à de nombreuses goroutines de coexister avec une quantité de mémoire modeste. Le surcoût en CPU est en moyenne de l'ordre de trois instructions par appel de fonction. On peut très bien créer des centaines de milliers de goroutines dans le même espace d'adressage. Si les goroutines étaient des threads, les ressources du système s'épuiseraient avec un nombre bien plus petit.

[Traduction de la FAQ officielle]

Après une longue discussion, il a été décidé que l'utilisation typique des maps ne nécessitait pas de mettre en place un mécanisme d'accès sécurisé de la part de goroutines multiples et que, dans les cas où cela s'avère nécessaire, alors la map fait sans doute partie d'une structure de données plus grande ou d'un calcul possédant déjà un mécanisme de synchronisation. Ainsi, exiger que toutes les opérations sur les maps prennent un mutex ralentirait la plupart des programmes et n’ajouterait de la sûreté que dans de rares cas. Cela n'a pas été une décision facile à prendre, cependant, car cela signifie qu'un accès non contrôlé à une map peut planter le programme.
Le langage n'empêche pas les mises à jour atomiques de maps. Au besoin, par exemple avec un programme dans lequel on n'a pas confiance, l'implémentation pourrait entraîner un interblocage sur l'accès à la map.

[Traduction de la FAQ officielle]

Il arrive fréquemment que des gens proposent des améliorations au langage. La liste de diffusion contient un riche historique de discussions de ce genre – mais très peu de ces changements ont été acceptés.
Bien que Go soit un projet open source, le langage et les bibliothèques sont protégés par un engagement de compatibilité interdisant les changements susceptibles d'introduire des dysfonctionnements de programmes existants. Si votre proposition viole la spécification de Go 1, nous ne pouvons même pas envisager l'idée, quel que soit son mérite. Il est possible qu'une future version majeure de Go soit incompatible avec Go 1, mais nous ne sommes pas prêts à discuter de ce qu'elle pourrait être.
Même si votre proposition est compatible avec la spécification de Go 1, elle n'est peut-être pas conforme à l'esprit des objectifs de conception de Go. L'article Go at Google : Language Design in the Service of Software Engineering explique les origines de Go et les motivations ayant présidé à la conception.