Mais les problèmes que tu pointes là sont du ressort de la conception de la bibliothèque standard (le choix d'avoir mis en avant la plus concrète (et donc plus simple) ou plus abstraite (et donc plus générique)) et des choix de documentation, pas de la définition du langage lui-même (on ne parle pas de changer les mots-clés, le typage, etc.) : on pourrait tout à fait avoir des classes de type correspondant aux interfaces Reader et Writer de la bibliothèque standard Go, et ce serait aussi simple à utiliser.
(Il y a une différence entre les deux usages, qui est qu'en Haskell (ou avec les implicites en Scala) il faut déclarer explicitement "le type truc est une instance de Reader avec telles méthodes", alors qu'en Go c'est automatique à partir du moment où une fonction du nom recherché existe. Je ne pense pas que l'un soit plus simple que l'autre pour un débutant. Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité—il y a des avantages et des inconvénients à chaque approche. On peut détailler un peu si ça intéresse des gens, mais ça concerne des usages plus avancés qui ne sont pas visibles pour le cas simple "classe standard pour la sérialisation".)
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4. Dernière modification le 20 octobre 2017 à 09:43.
Mais les problèmes que tu pointes là sont du ressort de la conception de la bibliothèque standard (le choix d'avoir mis en avant la plus concrète (et donc plus simple) ou plus abstraite (et donc plus générique)) et des choix de documentation, pas de la définition du langage lui-même (on ne parle pas de changer les mots-clés, le typage, etc.) : on pourrait tout à fait avoir des classes de type correspondant aux interfaces
ReaderetWriterde la bibliothèque standard Go, et ce serait aussi simple à utiliser.(Il y a une différence entre les deux usages, qui est qu'en Haskell (ou avec les implicites en Scala) il faut déclarer explicitement "le type truc est une instance de Reader avec telles méthodes", alors qu'en Go c'est automatique à partir du moment où une fonction du nom recherché existe. Je ne pense pas que l'un soit plus simple que l'autre pour un débutant. Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité—il y a des avantages et des inconvénients à chaque approche. On peut détailler un peu si ça intéresse des gens, mais ça concerne des usages plus avancés qui ne sont pas visibles pour le cas simple "classe standard pour la sérialisation".)