> Honnêtement, à part le fait que "c'est fait par Google donc saibien", je ne vois aucune amélioration objective
Pour l’avoir utilisé dans deux mini-projets (pour utilisation personnelle, mais qui tournent 100% du temps sur ma machine : un proxy DNS et un proxy HTTP):
Les plus:
- Passé quelques surprises, on retrouve finalement rapidement ses marques quand on a fait du C. Et je code plus efficacement qu’en C, au final (grâce, entre autre, aux types de base de bien plus haut niveau)
- Le système de typage est parfait. Disons plus modestement : c’est celui dont j’avais toujours rêvé
- Comme Python, "piles inclues" (librairie standard bien fournie)
- Le couple goroutine + channel, c’est également magique dès lors que tu as du multi-threading ; mon proxy DNS a un cache global dans lequel chaque client a une tâche lectrice et une tâche écrivain dessus. En multitâche classique, c’est le mal de crâne assuré pour synchroniser tout ce joli monde. En go, ça se fait tout seul (pas un seul mutex/sémaphore de tout le programme !)
- Le truc secondaire sur papier, absolument génialissime (et c’est encore un euphémisme) en pratique : le mot-clé defer.
Les moins:
- Le plus gros point, très gênant : le GC laisse passer des fuites de mémoire. Actuellement, mon proxy DNS tourne depuis trois jours, et utilise plus de 100 Mo de mémoire. Si je le redémarre, il n’en utilise plus que 5 Mo (et vu comme il est codé, le redémarrage ne devrait pas influer sur l’utilisation mémoire: le cache est sauvegardé sur disque puis rechargé au lancement)
- La librairie HTTP de base est... comment dire... totalement merdique. Ça c’est amélioré dans la version en développement, mais il y a encore un peu de boulot
- Interfaçage avec le C pas toujours trivial (et dès qu’il y a des pointeurs de fonction, ça devient VRAIMENT horrible)
- Ce que GCC met en "warning: unused xxx", Go en fait une erreur. C’est très énervant lors de la mise au point.
Pour ma part, il est définitivement adopté pour tout ce qui est "petits serveurs bas niveau" (typiquement : proxy HTTP qui ne touche pas au contenu des pages, proxy DNS, et pour la suite : filtre milter)
[^] # Re: grand avenir
Posté par Moonz . En réponse à la dépêche Le point sur les avancées de Google Go. Évalué à 9.
Pour l’avoir utilisé dans deux mini-projets (pour utilisation personnelle, mais qui tournent 100% du temps sur ma machine : un proxy DNS et un proxy HTTP):
Les plus:
- Passé quelques surprises, on retrouve finalement rapidement ses marques quand on a fait du C. Et je code plus efficacement qu’en C, au final (grâce, entre autre, aux types de base de bien plus haut niveau)
- Le système de typage est parfait. Disons plus modestement : c’est celui dont j’avais toujours rêvé
- Comme Python, "piles inclues" (librairie standard bien fournie)
- Le couple goroutine + channel, c’est également magique dès lors que tu as du multi-threading ; mon proxy DNS a un cache global dans lequel chaque client a une tâche lectrice et une tâche écrivain dessus. En multitâche classique, c’est le mal de crâne assuré pour synchroniser tout ce joli monde. En go, ça se fait tout seul (pas un seul mutex/sémaphore de tout le programme !)
- Le truc secondaire sur papier, absolument génialissime (et c’est encore un euphémisme) en pratique : le mot-clé defer.
Les moins:
- Le plus gros point, très gênant : le GC laisse passer des fuites de mémoire. Actuellement, mon proxy DNS tourne depuis trois jours, et utilise plus de 100 Mo de mémoire. Si je le redémarre, il n’en utilise plus que 5 Mo (et vu comme il est codé, le redémarrage ne devrait pas influer sur l’utilisation mémoire: le cache est sauvegardé sur disque puis rechargé au lancement)
- La librairie HTTP de base est... comment dire... totalement merdique. Ça c’est amélioré dans la version en développement, mais il y a encore un peu de boulot
- Interfaçage avec le C pas toujours trivial (et dès qu’il y a des pointeurs de fonction, ça devient VRAIMENT horrible)
- Ce que GCC met en "warning: unused xxx", Go en fait une erreur. C’est très énervant lors de la mise au point.
Pour ma part, il est définitivement adopté pour tout ce qui est "petits serveurs bas niveau" (typiquement : proxy HTTP qui ne touche pas au contenu des pages, proxy DNS, et pour la suite : filtre milter)