Afin d’améliorer ma culture de développeur, j’ai décidé d’apprendre le GO, qu’on voit de plus en plus pour des backend demandant de la performance.
Pour comprendre mon avis, il faut savoir que j’ai un profil de développeur backend pour des startups. Je code en Ruby (y compris avec EventMachine) au travail depuis plusieurs années, dans mes loisirs je fais du Python. J’ai pas mal joué avec Node.js y a un an, mais je n’étais totalement satisfait par l’aspect déploiement et la stabilité. J’ai aussi un bon background en C grâce à mes études à EPITECH.
Voilà donc mes premiers retours après une journée de GO. J’ai choisi d’écrire pour faire mes tests une application très simple qui va vérifier le DNS d’un grand nombre de domaines en même temps.
Je retrouve le slogan de Python “fourni avec les piles”. En effet de base les développeurs de GO fournissent pas mal d’outils de base pour la doc, les tests, le formatage du code, gestion des dépendances…
#La syntaxe
La syntaxe contient quelques bizarreries pour nos esprits formatés, mais rien d’insurmontable.
Par exemple la déclaration d’une fonction:
func TestDomain(domain string) bool {
}Cela nous donne une fonction TestDomain qui prend en argument un domain de type string et on retourne un bool.
Autre point qui parait bizarre au premier abord:
a := 1
a = 2L’opérateur := est un raccourci pour déclarer et affecter une variable. En effet le compilateur ne vous laisse pas utiliser une variable non déclarée.
On pourrait l’écrire ainsi:
var a;
a = 1
a = 2Point très positif pour moi, une commande gofmt est fournie avec le langage. Cela va reformater votre code selon les normes en vigueur dans le monde du GO. Cela coupe court au débat sur l’indentation, la place des parenthèses… Et on retrouve donc le confort de Python où deux codes sont formatés de la même manière.
VIM
Pas de problème de ce côté là j’ai installé VIM-GO qui fait le job:
- coloration syntaxique
- vérification des erreurs de syntaxe
- reformatage du code lorsqu’on sauvegarde avec gofmt
# Gestion de modules
Fournis de base avec le système vous pouvez téléchargez des modules (souvent hébergé sur Github).
go get github.com/noplay/madepDans votre code vous pouvez ensuite référencer le code en utilisant le même nom:
package main
import (
"github.com/noplay/madep"
"github.com/miekg/dns"
)Je trouve cela assez pratique, car on retrouve très facilement le site d’où vient un module.
La documentation
Pour le moment tous les modules que j’ai utilisés étaient bien documentés avec généralement un readme qui explique bien l’utilisation du module.
Une commande godoc vous permet d’afficher la documentation et via:
godoc -http=:6060Vous avez un serveur de documentation un local.
Les Goroutines
L’un des éléments qui rend le GO pratique pour la programmation concurrente est le concept des Goroutines. En effet pour lancer un traitement de tâches de fond il suffit de rajouté le mot-clef go devant l’appel. La fonction sera lancée en tâche de fond et votre code continuera son exécution.
go long_traitement()C’est une sorte de thread léger.
Les channels
Pouvoir lancer des tâches de fond c’est bien, mais encore faut il communiquer avec. C’est là qu’entre en oeuvre le concept de channels. Basiquement c’est un tube dans lequel on écrit d’un côté et on a une lecture bloquante de l’autre côté.
messages := make(chan string)
go func() { messages <- "hello" }()
msg := <-messages
fmt.Println(msg)C’est un système simple et qui s’avère efficace à l’usage.
Ce qu’il me reste à voir
Je n’ai pas encore testé le déploiement et c’est un point qui peut devenir compliqué sous Mac OS vu que cela implique de la cross compilation. Il y a aussi un framework de test fourni que je n’ai pas regardé.
Conclusion
Pour le moment j’ai une très bonne première impression sur GO. Le langage semble robuste et relativement simple de prise en main. Les concepts pour la programmation concurrente sont faciles à mettre en oeuvre. Par contre, cela ne remplacera par Ruby ou Python qui ont du sucre syntaxique qui rend certaines taches plus agréables (l’intégration des regex dans ruby par exemple).
Le fait de déployer juste un binaire en production me semble une bonne idée quand on voit les cauchemars dans lesquels on tombe vite lorsqu’on déploie du Ruby, du Python ou du Node.
La syntaxe me plait beaucoup plus que celle du C++ qui offre trop de possibilités ce qui fait qu’on se retrouve avec autant de C++ que d’endroit où l’on fait du C++.
