J'aime beaucoup go parce que sa syntaxe est claire et simple et que sa lib standard est cohérente et très fournie. Toutefois, je trouve que go a quelques problèmes fondamentaux cachés sous sa simplicité apparente.
Le polymorphisme en est un. Le système de type n'est tout simplement pas assez puissant. L'utilisation de l'héritage pour fournir un sypertype pour un ensemble de types à une fonction ou à une structure de donnée polymorphe atteint vite ses limites. Je ne comprends pas l'obsession des développeurs à éviter toute autre forme de polymorphisme (générics, ou autres).
Ces limites sont tellement présentes que les devs ont inclu des structures de données polymorphes dans le langage (maps, chans, et tableau) pour contourner les problèmes les plus courants. Toutefois, cela reste limité à ce que le langage supporte, et je trouve que go manque vite de flexibilité.
J'ai par exemple eu l'occasion d'écrire une DB en go, en utilisant des arrays comme zone mémoire dans laquelle gérer l'allocation de blocs (pour ne pas avoir à utiliser le GC et les objets natifs, ce qui s'avère lent pour une DB). J'avais donc besoin d'écrire deux structures de données qui sont des listes de tableaux (pour éviter le realloc), l'une étant un tableau de bytes, l'autre un tableau d'entiers. Cela est impossible sans écrire le code deux fois, ou sans utiliser de hack pour sérialiser les entiers en tableau de byte. En effet, il est impossible d'allouer une slice de manière polymorphe. Il faut spécifier statiquement le type de la slice, mais on ne peut pas faire ça sans préprocesseur, parce qu'il n'y a pas de génériques/templates/autre chose. De même, il n'y a pas de supertype qui inclue les slices/arrays/maps. Il faut passer une "factory" qui alloue des nouveaux blocs, et on se retrouver à recopier le même code pour int et byte.
j'ai beaucoup apprécié go au début, mais plus je l'ai utilisé et plus je l'ai trouvé bancal, et j'ai été très déçu par ce langage.
# Quelques problèmes fondamentaux
Posté par Enj0lras . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 10. Dernière modification le 17 novembre 2013 à 17:39.
J'aime beaucoup go parce que sa syntaxe est claire et simple et que sa lib standard est cohérente et très fournie. Toutefois, je trouve que go a quelques problèmes fondamentaux cachés sous sa simplicité apparente.
Le polymorphisme en est un. Le système de type n'est tout simplement pas assez puissant. L'utilisation de l'héritage pour fournir un sypertype pour un ensemble de types à une fonction ou à une structure de donnée polymorphe atteint vite ses limites. Je ne comprends pas l'obsession des développeurs à éviter toute autre forme de polymorphisme (générics, ou autres).
Ces limites sont tellement présentes que les devs ont inclu des structures de données polymorphes dans le langage (maps, chans, et tableau) pour contourner les problèmes les plus courants. Toutefois, cela reste limité à ce que le langage supporte, et je trouve que go manque vite de flexibilité.
J'ai par exemple eu l'occasion d'écrire une DB en go, en utilisant des arrays comme zone mémoire dans laquelle gérer l'allocation de blocs (pour ne pas avoir à utiliser le GC et les objets natifs, ce qui s'avère lent pour une DB). J'avais donc besoin d'écrire deux structures de données qui sont des listes de tableaux (pour éviter le realloc), l'une étant un tableau de bytes, l'autre un tableau d'entiers. Cela est impossible sans écrire le code deux fois, ou sans utiliser de hack pour sérialiser les entiers en tableau de byte. En effet, il est impossible d'allouer une slice de manière polymorphe. Il faut spécifier statiquement le type de la slice, mais on ne peut pas faire ça sans préprocesseur, parce qu'il n'y a pas de génériques/templates/autre chose. De même, il n'y a pas de supertype qui inclue les slices/arrays/maps. Il faut passer une "factory" qui alloue des nouveaux blocs, et on se retrouver à recopier le même code pour int et byte.
j'ai beaucoup apprécié go au début, mais plus je l'ai utilisé et plus je l'ai trouvé bancal, et j'ai été très déçu par ce langage.