The downsides
While generics may come in handy, they also have some strings attached.
Performance: Turning a generic code template into actual code takes time, either at compile time or at runtime.
C'est vrai, mais les différentes solutions existante en Go pour faire la même chose, ont exactement le même problème:
Finalement, au lieu d'avoir une méthode standard pour résoudre un problème bien connu, on a 5 méthodes différentes utilisées de manière arbitraire par chaque développeur. Brillant !
Dans leur dogmatisme à vouloir faire le truc le plus simple possible, les devs de Go refusent de voir une chose : dans le monde réel les besoins des gens sont compliqués, et ce n'est pas en faisant un langage simpliste qu'on va changer ça et si le langage ne fournit pas une façon standard de faire les choses dont les gens ont besoin, ils vont chacun développer leur propre méthode (souvent crade et mal pensée) pour résoudre leur problème et on se retrouve avec 50 façons différentes de faire la même chose.
C'est exactement avec ce genre de mécanisme en JavaScript [1] qu'on s'est retrouvé avec des dizaines de librairies pour faire des trucs basiques comme les promises, la programmation orientée objet ou les fonctions pour travailler sur des collections comme map et reduce. Il a fallu attendre 2015 et la sortie d'EcmaScript6 pour avoir ces trucs là intégrés dans le langage.
J'espère pour l'ensemble de la communauté de utilisateurs de Go qu'il ne faudra pas 20 ans à Rob Pike et ses potes pour ouvrir les yeux.
[1] mais c'était pour des pour des raisons différentes : pas par dogmatisme mais par manque de synchronisation entre les différents implémenteurs du langage (les différent navigateurs). Ça a nuit à tout le monde pendant des années, mais au moins ce n'était pas lié à la lubie de quelques-uns …