Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.
Ce point est à mon avis important.
La force de Go est d'être épuré au maximum (je crois qu'il n'y a que 18 mots clés) et donc de reduire au maximum l'effort cognitif pour appréhender le langage : pas trop de nouveaux concepts (bon, les coroutines et les channels c'est déjà pas mal) et un syntaxe claire et explicite.
Là où V se démarque, c'est justement dans ces petits choix syntaxiques qui apportent beaucoup de fluidités à l'écriture. Alors c'est vrai, c'est pas toujours très explicite (les variables "magiques" it, err etc.), mais ça rend le code assez léger.
Il y a un aspect moins formel que l'on retrouve généralement plus dans des langages comme python et javascript. Je viens personnellement du C++ à la base et j'ai rapidement été écœuré par le côté ésotérique de la syntaxe et les lenteurs de compilation, puis après j'ai plus codé dans des langages de scripts et ce qui m'écœure aujourd'hui c'est le manque de compilation en amont, le typage faible.
V tente de continué dans la lancé de Go, tout en allant peut-être plus loin dans l’expressivité du code et j'aime bien le résultat.
Après, je code "peu" en V, je lis beaucoup dessus, suit son développement de près, mais ça reste au stade d'expérimentation. Je comprends à 100% que l'on ne veuille pas s'y mettre.
PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^
Ah c'est assez étonnant comme remarque, car Zig est justement connu pour être explicite. Dans ce sens où il n'y a pas d'appel de fonction caché, pas d'allocation implicite.
Je trouve le choix d'intégré la gestion d'erreur comme un élément de la syntaxe plutôt judicieux. Cela limite la verbosité du code et rend la gestion d'erreur plus confortable.
J'ai tout de même l'impression qu'avec ces notions de Optional/Result on arrive à une sorte de consensus (ou plutôt de convergence) où beaucoup de langages récents ont fait le choix de traiter les erreurs et les retours de fonction de cette manière.
[^] # Re: Une gestion d’erreur moderne ?
Posté par Andréas Livet . En réponse à la dépêche À la découverte du langage V. Évalué à 2.
Ce point est à mon avis important.
La force de Go est d'être épuré au maximum (je crois qu'il n'y a que 18 mots clés) et donc de reduire au maximum l'effort cognitif pour appréhender le langage : pas trop de nouveaux concepts (bon, les coroutines et les channels c'est déjà pas mal) et un syntaxe claire et explicite.
Là où V se démarque, c'est justement dans ces petits choix syntaxiques qui apportent beaucoup de fluidités à l'écriture. Alors c'est vrai, c'est pas toujours très explicite (les variables "magiques"
it,erretc.), mais ça rend le code assez léger.Il y a un aspect moins formel que l'on retrouve généralement plus dans des langages comme python et javascript. Je viens personnellement du C++ à la base et j'ai rapidement été écœuré par le côté ésotérique de la syntaxe et les lenteurs de compilation, puis après j'ai plus codé dans des langages de scripts et ce qui m'écœure aujourd'hui c'est le manque de compilation en amont, le typage faible.
V tente de continué dans la lancé de Go, tout en allant peut-être plus loin dans l’expressivité du code et j'aime bien le résultat.
Après, je code "peu" en V, je lis beaucoup dessus, suit son développement de près, mais ça reste au stade d'expérimentation. Je comprends à 100% que l'on ne veuille pas s'y mettre.
Ah c'est assez étonnant comme remarque, car Zig est justement connu pour être explicite. Dans ce sens où il n'y a pas d'appel de fonction caché, pas d'allocation implicite.
Je trouve le choix d'intégré la gestion d'erreur comme un élément de la syntaxe plutôt judicieux. Cela limite la verbosité du code et rend la gestion d'erreur plus confortable.
J'ai tout de même l'impression qu'avec ces notions de Optional/Result on arrive à une sorte de consensus (ou plutôt de convergence) où beaucoup de langages récents ont fait le choix de traiter les erreurs et les retours de fonction de cette manière.