Une des regles principales de l'ecosysteme est de faire des API synchrones avec une gestion des erreurs explicites et laisser la decision de parallelisme a l'appelant. De plus, il est recommender d'eviter autant que possible d'utiliser les channels dans une API, car leur type ne permet pas a la lecture du prototype de savoir comment les utiliser pour synchroniser deux morceaux de code (buffer/unbuffered et blocking function ne sont pas dans le prototype). Du coup, l'utilisation des channels est plutot quelques choses d'interne.
De plus, meme si les channels sont tres optimise en Go, leur cout n'est pas nul. Aussi bien en memoire que CPU. Et comparer a un lock qui quand il n'est pas un point de contention, se comporte comme un atomic, il y a une difference assez importante en terme de performance.
Enfin comme tu peux le voir, il n'y a pas de besoin de synchronisation pour tous les utilisateurs de cette API, seul les developpeurs des data bindings de type simple ont du prendre cela en consideration. Cela rend l'utilisation de l'API simple et efficace avec aucune allocation memoire une fois que le binding est construit.
Pour repondre a tes questions supplementaires concernant la copie profonde, cela n'existe pas dans le language, car cela transformerait une affectation O(1) en une complexite inconnue. Cela veut dire que la copie profonde est a implementer manuellement et explicitement de maniere a bien en voir le cout (et du cout, on evite de faire des copies autant que possible :) ). Il n'y a pas de structure immutable en Go, uniquement des champs publiques ou prives (mais une fois qu'il y a des champs prives, il est impossible de juste copier une structure, il faut fournir une fonction pour pouvoir le faire).
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Une des regles principales de l'ecosysteme est de faire des API synchrones avec une gestion des erreurs explicites et laisser la decision de parallelisme a l'appelant. De plus, il est recommender d'eviter autant que possible d'utiliser les channels dans une API, car leur type ne permet pas a la lecture du prototype de savoir comment les utiliser pour synchroniser deux morceaux de code (buffer/unbuffered et blocking function ne sont pas dans le prototype). Du coup, l'utilisation des channels est plutot quelques choses d'interne.
De plus, meme si les channels sont tres optimise en Go, leur cout n'est pas nul. Aussi bien en memoire que CPU. Et comparer a un lock qui quand il n'est pas un point de contention, se comporte comme un atomic, il y a une difference assez importante en terme de performance.
Enfin comme tu peux le voir, il n'y a pas de besoin de synchronisation pour tous les utilisateurs de cette API, seul les developpeurs des data bindings de type simple ont du prendre cela en consideration. Cela rend l'utilisation de l'API simple et efficace avec aucune allocation memoire une fois que le binding est construit.
Pour repondre a tes questions supplementaires concernant la copie profonde, cela n'existe pas dans le language, car cela transformerait une affectation O(1) en une complexite inconnue. Cela veut dire que la copie profonde est a implementer manuellement et explicitement de maniere a bien en voir le cout (et du cout, on evite de faire des copies autant que possible :) ). Il n'y a pas de structure immutable en Go, uniquement des champs publiques ou prives (mais une fois qu'il y a des champs prives, il est impossible de juste copier une structure, il faut fournir une fonction pour pouvoir le faire).