Hier marquait le quatrième anniversaire du projet open-source. (Go1 a été publié en mars 2012 ; le quatrième anniversaire est calculé à partir de la création initiale du projet). Go a été créé par Robert Griesemer, Rob Pike et Ken Thompson chez Google, rejoints par Ian Taylor et Russ Cox avant qu'il ne soit open-source. Pourquoi Go :
Go est né de la frustration issue des langages et environnements existants pour la programmation système. Programmer était devenu trop difficile et le choix des langages est en partie à blâmer. Il fallait choisir entre une compilation efficace, une exécution efficace, ou la facilité de programmation, tous trois n'étaient pas disponibles dans un même langage dominant. Les programmeurs qui le pouvaient choisissaient la facilité d'écriture sur la sécurité et l'efficacité en choisissant des langages dynamiquement typés tels que Python et JavaScript plutôt que C++ ou, dans une moindre mesure, Java.
Go est une tentative de combiner la facilité de programmation d'un langage interprété, typé dynamiquement avec l'efficacité et la sécurité d'un langage compilé et statiquement typé. Il vise également à être moderne, avec le support des aspects réseaux et de la programmation multi-coeurs. Enfin, il est destiné à être rapide : il devrait prendre au plus quelques secondes pour construire un gros exécutable sur un seul ordinateur. Pour atteindre ces objectifs il fallait résoudre un certain nombre de questions linguistiques : un système de type expressif mais léger, la concurrence et le garbage collector, une spécification de dépendance rigide, et ainsi de suite. Ceux-ci ne pouvant être traités bien par des bibliothèques ou des outils, un nouveau langage a été demandé.
La version la plus récente de Go est la 1.1, sortie en mai 2013. Go 1.2 est prévue pour la fin de ce mois, avec dans le même temps un document de compatibilité qui définit la compatibilité des futurs programmes avec Go 1, suggérant une approche prospective de compatibilité, quelque chose dont manquent les autres langages compilés.
Depuis son lancement initial, un certain nombre d'entreprises ont commencé à utiliser Go, y compris Docker, un outil pour packager des applications dans des conteneurs légers, Packer, un outil pour automatiser la création d'images système, NSQ de Bitly, qui fournit une plate-forme de messagerie distribuée, JuJu de Canonical, qui prévoit un système d'automatisation de l'infrastructure, et bien d'autres. Même la Free Software Foundation discute du remplacement de Java par Go comme langage par défaut. L'équipe de Docker a donné une présentation sur leur choix d'utiliser Go.
Le principal avantage pour les personnes DevOps est que les programmes de Go sont toujours liés statiquement dans un fichier exécutable unique qui peut être déployé sur la plate-forme cible. En conséquence, le système n'a pas besoin d'avoir des binaires supplémentaires pré-installés et peut se permettre d'utiliser différentes versions côte-à-côte sans conflit. On peut comparer cela aux systèmes de packaging tels que ceux de Linux et Java qui ont leurs bibliothèques réparties sur plusieurs sites et nécessitent soit une configuration spécifique en place soit un résolveur pour trouver les dépendances à l'avance. (L'inconvénient est que les bibliothèques communes sont répétées dans les binaires statiques de tous les programmes, mais l'espace disque n'est pas cher. La consommation mémoire sur les serveurs, qui, autrement, seraient capable de charger une seule image de la bibliothèque est peut-être un problème plus réaliste pour les systèmes avec de nombreux processus en cours d'exécution)
Le principal avantage pour la haute disponibilité et les programmes multithread est l'utilisation des goroutines de GO, qui permettent plusieurs threads d'exécution pour répondre aux requêtes entrantes d'une manière similaire à ce qui est fait avec Erlang ou Occam. Tous les trois sont basés sur des processus séquentiels de communication ou CSP (Communicating Sequential Processes). Au lieu d'avoir à traiter avec la mémoire et la gestion des threads, les CSP ont chacun une file d'attente de messages entrants/tâches, et peuvent à leur tour envoyer ces messages/tâches à d'autres CSP. Il y a des opérations bloquantes et asynchrones et chaque opération bloquante peut avoir une valeur de retour généralement envoyée sous forme de message de retour à la CSP d'origine.
Cloud Foundry est récemment passé de Ruby à Go pour son outil en ligne de commande, afin d'éviter tout pré-requis particulier pour utiliser les commandes. En fait, c'est maintenant un outil léger pour communiquer avec les services de back-end, et au lieu de laisser le client effectuer des routines de validation complexes, il communique désormais avec un service de back-end pour faire le gros du travail. Cela signifie que l'outil d'aujourd'hui n'a plus besoin d'être mis à jour fréquemment, et il est aussi plus petit.
Avec Go 1.2 attendue dans les prochaines semaines, il va y avoir un changement supplémentaire dans le langage, les slices à triple index seront désormais possibles. Lorsque auparavant une expression a[1:10] aurait coupé les éléments du tableau de 1 à 10, maintenant l'expression [1:2:10] va supprimer toutes les autres valeurs. Une petite précision sur l'endroit où nil est utilisé provoquera une panique si déréférencé. D'autres modifications sont indiquées dans les notes de version.
Les critiques de Go soulignent que le langage utilise un style ancien pour les codes de retour au lieu des styles plus largement adoptés, basés sur les exceptions, et que, contrairement à Erlang (qui, en tant que langage fonctionnel n'a pas d'état mutable), les goroutines peuvent passer des maps qui ne sont pas synchronisées par défaut, ce qui entraîne une corruption de mémoire. Il est clair que Go s'applique bien à certains cas d'utilisation niches, et quelles que soient les comparaisons que l'on peut faire avec des langages comme Java et Erlang, Go peut être considéré comme une alternative légère et peut-être plus sûr que du C brut.