woffer 🐧 a écrit 238 commentaires

les goroutines engendrent facilement des "data race" etc… On est vite refroidi !

Ah oui, j'oubliai le détecteur de race condition. Pour en avoir détecter plusieurs, c'est vraiment un outil qui est très utile.
Pour l'activer, il suffit de compiler le binaire avec l'option -race.
Le détecteur de race condition remonte uniquement des vrais positifs (il peut donc en laisser passer), donc ils faut toujours prendre au sérieux les alertes remontées (elles sont remontées dans la STDERR via une stack trace des deux goroutine impliquées et qd elles ont été créées).

Autre point, le fait de l'activer, cela va consommer en terme de mémoire et d'usage CPU. Donc, on :
- doit passer tous ses tests unitaire/microbenching avec le détecteur activé et cela dès le début du projet.
- peut imaginer l'activer sur une partie de votre cluster.

Je n'ai jamais vérifié comment fonctionne exactement go get mais je pense que d'enlever les imports non utilisés doit aussi faciliter la tâche de l'analyseur pour descendre les sources et ses dépendances.

Jamais testé.
Mais je pense que les structures implémentant la fonction des deux interfaces peuvent être vue comme l'une ou l'autre interface.

La on tape un peu n'importe comment et hop un coup de gofmt à l'enregistrement et on a un code propre comme pas deux.

J'aime bien le formatage gofmt, mais j’apprécie beaucoup plus celui de goimports qui va :
- faire le formatage de "base" de gofmt
- enlever les imports inutilisés (sinon erreur de compilation)
- classer par ordre alphanumérique et grouper les dépendances externes

On perd énormément niveau sécurité du typage.

Ce qu'il faut savoir ce que Go n'est pas vraiment du duck typing car la validation est faite à la compilation et non runtime.
Donc l'erreur sera détectée à la compilation avec une erreur détaillée.

Je pratique ce langage depuis plus de 2 ans avec un background Java [Spring/Spring Boot] principalement.
J’apprécie dans ce langage :
- Sa simplicité, tout est dans le code, pas besoin d'aller voir un fichier xml pour comprendre le comportement d'un bout de code ou une injection de dépendance (un pique contre Spring)
- Sa compilation pas de choses mystérieuses/magiques au runtime (un autre pique contre Spring)
- Sa communauté très réactive/sympathique/compétente
- Son outillage très complet (profiling cpu/mémoire, formatage de code, fuzzing)
- Sa concurrence simplissime et performante (c'est un langage monte très bien en charge) grâce aux goroutines
- Un écosystème complet avec une multitude de librairies disponibles
- Un sobriété sur l'usage de la mémoire largement supérieur à Java (pour diverses raisons)
- La possibilité d'écrire du code (sync.Pool) qui limite l'allocation dynamique de la mémoire, et de le tester via du microbenchmark. Ce permet de limiter l'usage du garbage collector pour avoir des applications vraiment performantes (comme l'indique Brad Fitzpatrick un des gurus de Go dans cette vidéo ou ici)

Il y a aussi des manques dans ce langage :
- D'un débogueur fiable et multi-plateforme (même si cela change avec Delve)
- Les generics afin d’éviter les insertions de type qui peuvent générer des erreurs au runtime

Bref, je pourrais en parler des heures mais le temps me manque :)

Effectivement, la simplicité d'utilisation de ces outil et leur disponibilité grâce à leur licence les rendent complètement génial.
On peut facilement imaginer mettre ce genre d'outil dans nos processus d'intégration continue (via un Jenkins ou autres) et les faire tourner toutes les nuits durant nos processus de développement afin de trouver au plus tôt une partie importante des failles/crashs.

Comme le mécanisme de corpus est simple à mettre en place mais surtout très efficace. Le mécanisme de fuzzing s'adaptera dans la nuit aux évolutions du logiciel faites dans la journée.

Bref, j'adore :)

C'est une façon de dire que ce n'est pas si efficace que ça ? ;-p

Je ne connais pas SAGE de Microsoft.
Par contre, je peux te dire que la stratégie de fuzzing détaillée dans l'article lwn est très efficace.
J'ai pu la mettre en pratique sur un stack réseau interne écrite en Go, et go-fuzz m'a trouvé tout un tas de d'accès en dehors des limites de divers tableaux et surtout une belle boucle infinie avec une belle fuite mémoire en prime.

Effectivement, je ne mettrai pas spécialement la lisibilité de go en avant car c'est surtout une affaire de goût et d'habitude.
Par contre, la concurrence, son déploiement simple (un seul binaire) sont, pour moi et parmi d'autres choses, des gros avantages.

Merci, c'est ça!

Nope, cela dépend du masque du réseau.
La règle est :
IP réseau & masque du réseau doit être égal à l'IP réseau

Loin de moi, l'idée de lancer un troll. J'exposais juste un état de fait pour un utilisateur d'une debian à la maison que je suis.
Je sais bien que debian lenny est sortie en début d'année et que la philosophie debian est d'avoir une branche stable avec des logiciels/librairies éprouvés longuement mais avec un léger coût : la relative obsolescence des paquets. C'est tous.

Ce post a eu au moins l'avantage de d'avertir le mainteneur (que je salue pour sa réactivité) du paquet SuperCopier afin de lui indiquer que son paquet n'était pas compatible en l'état avec la debian stable c'est à dire lenny.

Je vais pouvoir tester pour voir exactement ce que ca donne sous Linux (déjà testé sur un windaube...)

Oui mais pas avec Debian Lenny.
Il semble que le package est compilé avec libqt4-core (>= 4.5.0)
Sous Debian Lenny, j'ai uniquement la version antérieur, dommage pour moi.
J'ai pas envie de compiler c'est mon coté débianiste fainéant ;)
Librement votre