• [^] # Re: Go est lent, Rust est rouillé !

    Posté par . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 7. Dernière modification le 29 avril 2020 à 11:10.

    Une vision plus positive de la même chose serait : si on veut vraiment filter ou any en Go, on peut du moment qu'on accepte que cette partie du code ait les mêmes garanties qu'en Ruby :-)

    Oui mais :

    1. c'est très frustrant pour le développeur de perdre l'information de type juste à cause du système de type. Une fonction foo(interface{}) interface{} qui renvoie systématiquement le même type que ce qu'elle a reçu, tu es obligé de gérer des cas que tu sais inutiles juste parce que le typage n'est pas propagé
    2. Go n'est pas Ruby. Un langage globalement typé dynamiquement te pousse à tout le temps vivre avec ce genre de choses. C'est prévu par le langage1 et tu as une homogénéité sur l'ensemble de ton code. Là tu crée une section de ton code qui n'a plus le même typage. C'est un piège plus vicieux.

    1. entre autre l'obligation de passer par un cast par rapport au fait d'utiliser un langage dynamique te pousse à pousser plus de contraintes sur le type que ce dont tu as besoin. Si tu a une interface qui défini 2 méthodes foo() et bar() tu va avoir tendance à la réutiliser même si tu a besoin que de l'une des 2. Un autre point peut être que les langages dynamiques possèdent aussi beaucoup plus d'informations de type au runtime. Ça donne des erreurs plus compréhensible. ↩

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll