Re: "Billion dollar mistake"

dans l'autre cas, on a un type Result choisir d'ignorer explicitement

Le truc, c'est qu'entre choisir d'ignorer explicitement (volontairement ou par erreur d'inattention) et le faire sans faire exprès dans le cas de Go où, comme je précise plus bas, il y a au moins 3 raisons qui font que c'est très peu probable (par rapport à du C, par exemple), c'est en pratique très similaire à mon avis, même si d'un point de vue purement théorie des types c'est différent.

Un nil dans ce genre de langage n'est pas typé, puisque rien de distingue un nil d'un autre, si je puis m'exprimer ainsi.

Heu, en C oui, mais en Go nil est bien typé : tu ne peux pas utiliser un nil d'un type de pointeur donné comme un nil d'un autre type de pointeur, tout ça est vérifié à la compilation ; nil est dans les faits comme un type option en Go (c'est nil d'un certain type particulier, bref Option<Type>::None), sauf que les syntaxes d'accès à la valeur font un unwrap (explicite dans la syntaxe), ce qui demande un check préalable != nil quand on veut les utiliser.

Le fait d'avoir des références nulles fait qu'il y a un typage faible localement.

Eh bien pas dans le cas de Go, qui est plutôt fortement typé : typage faible c'est lorsque tu as des conversions implicites où des comportements imprévisible, arithmétiques de pointeur, etc. Go n'a rien de tout ça (pas même de conversions implicites entre différents types d'entiers, encore moins entre différents types de nil).

Pour avoir utilisé les 2 types de gestion d'erreur, je fais tout pour éviter les langages avec référence nulle qui obligent à vérifier tout le temps qu'on a bien un objet valide.

Eh bien, pour avoir utilisé les deux types de langages aussi (j'ai fait du OCaml, quelques petits projets en Haskell et fait 20KLOC de Coq), je n'ai à aucun moment eu l'impression que, pour la gestion d'erreur, je perdais grand chose en passant à Go. En Go, quand tu écris v, err := ... c'est pas évident d'oublier de gérer avec if err != nil {...} après : 1) ça devient un réflexe car convention respectée partout dans le langage, 2) si err n'est pas utilisé le compilateur se plaint, 3) il y a des linteur qui vont te donner des warnings sur des cas un peu plus complexes (tu utiliserais err sans checker s'il est nil, par exemple).

Je fais de loin beaucoup plus d'erreurs de logique (faisables en OCaml, Rust comme en Go), que d'étourderies en ce genre et, les rares étourderies de ce genre, j'ai toujours pu les corriger en un rien de temps; c'est les erreurs de logique qui me font perdre du temps. En Coq tu peux spécifier les comportements et là ça devient vraiment intéressant (et tout aussi gourmand en temps de développement), mais en OCaml, Rust ou Haskell la plupart des erreurs sont en pratique les mêmes qu'en Go. En C, ce serait une autre histoire, bien sûr.