La GopherCon 2018 s’est déroulée du 27 au 30 Août 2018 à Denver dans le Colorado. Evénement incontournable de la communauté Go, elle nous a permis d’en savoir un peu plus sur l’avenir de notre langage favori et plus précisément d’entrevoir les nouveautés de cette mouture v2.

C’est à travers cette courte vidéo diffusée lors de la conférence, que les participants ont pu découvrir les 3 thématiques majeures de cette release v2.

On y apprend que le sondage réalisé en 2017 auprès de la communauté a mis en exergue 3 attentes :

• Une meilleure gestion des dépendances
• Un traitement des erreurs plus pratique et plus complet
• L’ajout des types génériques

Dépendances

On a vu émerger Dep, qui s’est imposé comme le gestionnaire de dépendances de référence jusqu’à ces dernières semaines. Finalement une autre approche à vue le jour avec l’apparition des modules.

La version de Go 1.11 récemment sortie, propose d’ores et déjà cette nouvelle fonctionnalité. Vous trouverez plus d’informations à ce sujet dans cet article de Dave Cheney.

Gestion des erreurs

Concernant la gestion des erreurs, vous qui lisez ces lignes connaissez bien le pattern suivant :

if err != nil {
	return err
}

C’est un pattern de gestion d’erreur simple, en effet, les erreurs sont traitées comme des valeurs qu’on retourne. Le revers de le médaille c’est qu’on retrouve ce pattern très — voire trop — souvent dans notre code, cela l’alourdit et pénalise la lisibilité.

Le draft de Go2 propose une approche un peu différente en introduisant un nouveau mot clé check.

func printSum(a, b string) error {
	handle err {
		return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
	}
	x := check strconv.Atoi(a)
	y := check strconv.Atoi(b)
	fmt.Println("result:", x + y)
	return nil
}

On obtient un code plus lisible tout en permettant d’ajouter plus facilement du contexte à notre erreur.

Si vous voulez en savoir plus, lisez la proposition du draft sur la gestion des erreurs.

D’ailleurs en parlant de contexte, un autre axe d’amélioration des erreurs propose d’ajouter plus aisément des informations contextuelles, on retrouve les détails sur cette proposition concernant les valeurs des erreurs.

Types génériques

La dernière proposition, mais pas des moindres, traite de l’ajout des types génériques. Vaste sujet s’il en est, car depuis que je fais du Go, j’ai toujours observé du coin de l’œil la communauté débattre autour de ce sujet.

En effet, il est souvent reproché à Go de ne pas proposer cette fonctionnalité, même si des solutions alternatives existent aujourd’hui. Il semble que la communauté ait été entendue ! Cette fois c’est le mot clé contract qui fait son apparition. Les débats sont déjà ouverts sur leur ressemblance avec interface.

contract stringer(x T) {
	var s string = x.String()
}

func Stringify(type T stringer)(s []T) (ret []string) {
	for _, v := range s {
		ret = append(ret, v.String())
	}
	return ret
}

On voit dès lors comment on pourrait désormais mutualiser du code, alors qu’aujourd’hui il nous faudrait créer une fonction pour chaque type que l’on souhaite utiliser.

Vous retrouverez les détails de cette proposition dans cette page consacrée à l’introduction des contrats.

Que pensez-vous de ces évolutions ? N’hésitez pas à réagir ci-dessous !