Il y a tellement de trucs mal foutus dans Go (l'absence de généricité, les paniques, les variables ombragés, les rondelles de tableaux...)
Que verrais-tu à la place des panics ? C'est une forme minimale d'exceptions pour les cas vraiment exceptionnels (correspondant à des erreurs de programmation en général : recover n'est utilisé que dans de rares occasions) qu'il est difficile d'éviter : Rust fait un panic aussi par exemple lors d'un accès tableau mal indexé.
Les variables ombragées peuvent en effet parfois conduire à une surprise, c'est indéniable, mais je pense que le choix a été fait en connaissance de cause. Elles sont parfois utiles sur le moment lors de refactoring (ça évite de renommer inutilement des variables) ou juste parce qu'utiliser une variable avec le même nom dans un bloc est intuitif (genre err) et qu'utiliser de la mutation plutôt que du shadowing aurait été encore plus problématique. Cela dit, il y a des outils d'analyse statique qui détectent les variables ombragées, et certains cas typiques sont même détectés de base (par exemple si variable non utilisée, ou variable de retour ombragée avant return).
Pour ce qui est des rondelles de tableau, je ne suis pas sûr de savoir à quoi tu fais référence ;-) Si tu fais référence aux slices, je trouve au contraire que c'est une partie très réussie du langage, donc je serais curieux de savoir ce que tu leur reproches ? Ils ont un côté un peu subtil par rapport à de simples tableaux, mais le concept est puissant et s'inspire à la fois des classiques tableaux dynamiques à la Python ou Perl ainsi de ce que l'on retrouve (sous une forme n-dimensionnelle plus complexe) dans les bibliothèques numériques pour d'autres langages qui permettent de sélectionner des fenêtres/slices.
[^] # Re: Ouaiche
Posté par anaseto . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 3.
Que verrais-tu à la place des panics ? C'est une forme minimale d'exceptions pour les cas vraiment exceptionnels (correspondant à des erreurs de programmation en général : recover n'est utilisé que dans de rares occasions) qu'il est difficile d'éviter : Rust fait un panic aussi par exemple lors d'un accès tableau mal indexé.
Les variables ombragées peuvent en effet parfois conduire à une surprise, c'est indéniable, mais je pense que le choix a été fait en connaissance de cause. Elles sont parfois utiles sur le moment lors de refactoring (ça évite de renommer inutilement des variables) ou juste parce qu'utiliser une variable avec le même nom dans un bloc est intuitif (genre
err) et qu'utiliser de la mutation plutôt que du shadowing aurait été encore plus problématique. Cela dit, il y a des outils d'analyse statique qui détectent les variables ombragées, et certains cas typiques sont même détectés de base (par exemple si variable non utilisée, ou variable de retour ombragée avant return).Pour ce qui est des rondelles de tableau, je ne suis pas sûr de savoir à quoi tu fais référence ;-) Si tu fais référence aux slices, je trouve au contraire que c'est une partie très réussie du langage, donc je serais curieux de savoir ce que tu leur reproches ? Ils ont un côté un peu subtil par rapport à de simples tableaux, mais le concept est puissant et s'inspire à la fois des classiques tableaux dynamiques à la Python ou Perl ainsi de ce que l'on retrouve (sous une forme n-dimensionnelle plus complexe) dans les bibliothèques numériques pour d'autres langages qui permettent de sélectionner des fenêtres/slices.