Donc non, c'est clair, vous n'avez pas la somme de deux types en Go, jusqu'à preuve du contraire. Ou si vous l'aviez, il faudra m'expliquer la raison étrange d'avoir choisi le produit, et non la somme, comme convention pour vos fonctions pouvant retourner une erreur (ce qui est le point de départ de toute cette discussion).
Parce c'est plus simple pour le flot de contrôle et se gère plus naturellement et légèrement avec les structures de contrôle impératives classiques déjà présentes. Go n'est pas un langage où les gens veulent une étude continue de nouvelles fonctionnalités syntaxiques.
Les extensions de syntaxes ppx dérivent un pretty printer (pp) à utiliser comme celui fournit par défaut pour les int. Ce qui revient tout à fait au même que votre printf en Go, mais avec un système de types un peu plus sérieux.
La notion de système de types sérieux ou non n'est pas constructive : perso, je comprends que c'est une façon de transmettre ton ressenti et, connaissant bien OCaml, je peux prendre ça avec recul. Mais si je ne connaissais pas OCaml, je pourrais naïvement croire que le système de types de Go est clairement mauvais et croire aux allégations mal informées d'ignorance académique de ses créateurs ou autre : oui, ils ne sont pas des chercheurs en systèmes de types avancés, mais un langage de programmation ne se limite pas à ça.
Le but d'un langage de programmation, ce n'est pas son système de typage, c'est d'écrire des programmes qui répondent à des besoins. Et concernant le typage, tout n'est pas question de puissance, mais aussi d'accessibilité en pratique : c'est pas pour rien que les modules en OCaml sont sous-utilisés et considérés un concept pour non-débutants par rapport aux interfaces Go, accessibles aux débutants, par exemple. Le but des types somme pour les errerus, c'est de bien gérer ces erreurs : d'autres approches comme celle de Go permettent statistiquement de bien gérer les erreurs aussi (voire mieux que les exceptions OCaml), sont-elles moins sérieuses ? La réflection permet grâce au marshalling de sauver facilement un état (par exemple sauvegarde pour un jeu) sans avoir à écrire de code, c'est une application pratique, peu importe le sérieux de l'approche par rapport à une autre approche qui ne propose pas encore d'équivalent simple.
[^] # Re: Raisons d'essayer Rust
Posté par anaseto . En réponse au journal Retour d'expérience sur les langages de programmation. Évalué à 4. Dernière modification le 19 novembre 2020 à 17:27.
Parce c'est plus simple pour le flot de contrôle et se gère plus naturellement et légèrement avec les structures de contrôle impératives classiques déjà présentes. Go n'est pas un langage où les gens veulent une étude continue de nouvelles fonctionnalités syntaxiques.
La notion de système de types sérieux ou non n'est pas constructive : perso, je comprends que c'est une façon de transmettre ton ressenti et, connaissant bien OCaml, je peux prendre ça avec recul. Mais si je ne connaissais pas OCaml, je pourrais naïvement croire que le système de types de Go est clairement mauvais et croire aux allégations mal informées d'ignorance académique de ses créateurs ou autre : oui, ils ne sont pas des chercheurs en systèmes de types avancés, mais un langage de programmation ne se limite pas à ça.
Le but d'un langage de programmation, ce n'est pas son système de typage, c'est d'écrire des programmes qui répondent à des besoins. Et concernant le typage, tout n'est pas question de puissance, mais aussi d'accessibilité en pratique : c'est pas pour rien que les modules en OCaml sont sous-utilisés et considérés un concept pour non-débutants par rapport aux interfaces Go, accessibles aux débutants, par exemple. Le but des types somme pour les errerus, c'est de bien gérer ces erreurs : d'autres approches comme celle de Go permettent statistiquement de bien gérer les erreurs aussi (voire mieux que les exceptions OCaml), sont-elles moins sérieuses ? La réflection permet grâce au marshalling de sauver facilement un état (par exemple sauvegarde pour un jeu) sans avoir à écrire de code, c'est une application pratique, peu importe le sérieux de l'approche par rapport à une autre approche qui ne propose pas encore d'équivalent simple.