Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++. Équivalent, ça veut dire qu'on peut remplacer l'un par l'autre, et réciproquement. Mais il est absolument impossible d'utiliser les interfaces (concept relativement simple et à l'usage bien délimité) pour remplacer tous les usages des templates C++ (gros tas de fonctionnalité extrêmement complexe, sous-langage Turing-complet exécuté à la compilation).
Ensuite, votre préoccupation pour les performances de la résolution des méthodes est déplacée dans la majorité des cas. Les efforts d'implémentation du langage Self ont montré qu'on pouvait obtenir d'excellentes performances en optimisant un langage où toutes les résolutions sont dynamiques.
La description de l'implémentation actuelle des interfaces de Go est décrite par exemple dans ce billet (trouvé il y a 5 minutes sur Google). Si j'ai bien compris après lecture rapide, les tables sont calculées au moment de l'initialisation des objets, et ensuite les appels sont de simples appels indirects. On peut imaginer de nombreuses optimisations (des heuristiques pour faire des paris statiques sur la table à initialiser), mais il n'y en a sans doute pas besoin pour avoir des performances tout à fait raisonnables.
Et je ne joue pas l'air de flûte bien connu "les ordinateurs sont plus rapide, on peut avoir des langages plus lents". Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes. Par exemple on a beau dire que la gestion manuelle de la mémoire en C ou C++ c'est top génial, et hurler dès qu'un langage se prétendant rapide intègre un GC, au final les gens qui codent en C ou C++ mais ne veulent pas des bugs absurdes liés à la gestion de la mémoire doivent se servir de bibliothèques de gestion de mémoire (shared_ptr, Boehm GC...) qui sont beaucoup plus lentes que ce qu'on fait dans un langage haut niveau bien compilé, parce que la sémantique du langage ne permet pas de faire ça de façon précise et performante.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 5.
Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++. Équivalent, ça veut dire qu'on peut remplacer l'un par l'autre, et réciproquement. Mais il est absolument impossible d'utiliser les interfaces (concept relativement simple et à l'usage bien délimité) pour remplacer tous les usages des templates C++ (gros tas de fonctionnalité extrêmement complexe, sous-langage Turing-complet exécuté à la compilation).
Ensuite, votre préoccupation pour les performances de la résolution des méthodes est déplacée dans la majorité des cas. Les efforts d'implémentation du langage Self ont montré qu'on pouvait obtenir d'excellentes performances en optimisant un langage où toutes les résolutions sont dynamiques.
La description de l'implémentation actuelle des interfaces de Go est décrite par exemple dans ce billet (trouvé il y a 5 minutes sur Google). Si j'ai bien compris après lecture rapide, les tables sont calculées au moment de l'initialisation des objets, et ensuite les appels sont de simples appels indirects. On peut imaginer de nombreuses optimisations (des heuristiques pour faire des paris statiques sur la table à initialiser), mais il n'y en a sans doute pas besoin pour avoir des performances tout à fait raisonnables.
Et je ne joue pas l'air de flûte bien connu "les ordinateurs sont plus rapide, on peut avoir des langages plus lents". Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes. Par exemple on a beau dire que la gestion manuelle de la mémoire en C ou C++ c'est top génial, et hurler dès qu'un langage se prétendant rapide intègre un GC, au final les gens qui codent en C ou C++ mais ne veulent pas des bugs absurdes liés à la gestion de la mémoire doivent se servir de bibliothèques de gestion de mémoire (shared_ptr, Boehm GC...) qui sont beaucoup plus lentes que ce qu'on fait dans un langage haut niveau bien compilé, parce que la sémantique du langage ne permet pas de faire ça de façon précise et performante.