c'est très frustrant pour le développeur de perdre l'information de type juste à cause du système de type.
Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre. Tu n'es pas plus obligé de gérer les "cas inutiles" que dans un langage dynamique : si tu es confiant, tu peux traiter que le cas qui est censé arriver, avec panic sinon (comme dans un langage dynamique). Tu as le choix d'écrire ton code de façon plus défensive, mais c'est pas une obligation (ni même toujours recommandé).
Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide). Go a toute l'information qu'il faut sur ses types "dynamiques" au runtime. Quand je dis que Go a une partie dynamique, c'est pas vraiment d'un point de vue du typage : techniquement parlant Go est 100% statique pour ce qui est du typage en soi, car les casts explicites sont typés (tant la source que le retour), de la même façon qu'une fonction StringToInt dans un langage quelconque renvoyant Int ou une erreur peut être typée statiquement. C'est pas comme un cast en C qui doit impérativement être correct sous risque de faire des trucs unsafe : en Go un cast est safe (d'un point de vue typage), encore plus qu'au sens d'un accès tableau en Rust/OCaml/etc, car on a le choix de gérer le cas d'erreur.
J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique (au sens large). Aucun langage n'est totalement ni l'un (à part l'assembleur peut-être) ni l'autre (outre Coq et compagnie) : les langages à typage statique ont généralement des tests dynamiques pour les accès tableau (avec panic), pour certaines fonctions de marshalling/sérialisation, parfois via réflection (Java ou Go, donc typé statiquement même si dynamique) ou carrément type unsafe (OCaml), exceptions qui échappent au système de types (OCaml et plein d'autres), etc. ; les langages dynamiques offrent parfois un minimum de typage statique pour différencier certaines choses (une fonction d'une variable, voire dans certains langages comme Perl, un tableau d'un scalaire). À mon avis, avec Go, il est prévu par le langage d'utiliser des checks dynamiques pour les cas nécessitant un système de types plus complexe, au même titre qu'en Ruby il est prévu que tout soit dynamique.
Entre dynamique et statique il y a tout un monde : comme mentionné plus haut, même Rust évite un système de types plus complexe qui permettrait d'éviter des checks runtime pour les accès tableau. C'est une question de juste milieu : on sait que les extrêmes sont pas vraiment pratiques pour les usages courants (du genre Coq vs Assembleur), mais par contre il n'y a pas de réponse définitive pour dire où le juste milieu doit se trouver pour un langage généraliste.
[^] # Re: Go est lent, Rust est rouillé !
Posté par anaseto . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 3.
Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre. Tu n'es pas plus obligé de gérer les "cas inutiles" que dans un langage dynamique : si tu es confiant, tu peux traiter que le cas qui est censé arriver, avec panic sinon (comme dans un langage dynamique). Tu as le choix d'écrire ton code de façon plus défensive, mais c'est pas une obligation (ni même toujours recommandé).
Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide). Go a toute l'information qu'il faut sur ses types "dynamiques" au runtime. Quand je dis que Go a une partie dynamique, c'est pas vraiment d'un point de vue du typage : techniquement parlant Go est 100% statique pour ce qui est du typage en soi, car les casts explicites sont typés (tant la source que le retour), de la même façon qu'une fonction StringToInt dans un langage quelconque renvoyant Int ou une erreur peut être typée statiquement. C'est pas comme un cast en C qui doit impérativement être correct sous risque de faire des trucs unsafe : en Go un cast est safe (d'un point de vue typage), encore plus qu'au sens d'un accès tableau en Rust/OCaml/etc, car on a le choix de gérer le cas d'erreur.
J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique (au sens large). Aucun langage n'est totalement ni l'un (à part l'assembleur peut-être) ni l'autre (outre Coq et compagnie) : les langages à typage statique ont généralement des tests dynamiques pour les accès tableau (avec panic), pour certaines fonctions de marshalling/sérialisation, parfois via réflection (Java ou Go, donc typé statiquement même si dynamique) ou carrément type unsafe (OCaml), exceptions qui échappent au système de types (OCaml et plein d'autres), etc. ; les langages dynamiques offrent parfois un minimum de typage statique pour différencier certaines choses (une fonction d'une variable, voire dans certains langages comme Perl, un tableau d'un scalaire). À mon avis, avec Go, il est prévu par le langage d'utiliser des checks dynamiques pour les cas nécessitant un système de types plus complexe, au même titre qu'en Ruby il est prévu que tout soit dynamique.
Entre dynamique et statique il y a tout un monde : comme mentionné plus haut, même Rust évite un système de types plus complexe qui permettrait d'éviter des checks runtime pour les accès tableau. C'est une question de juste milieu : on sait que les extrêmes sont pas vraiment pratiques pour les usages courants (du genre Coq vs Assembleur), mais par contre il n'y a pas de réponse définitive pour dire où le juste milieu doit se trouver pour un langage généraliste.