Google's Go est-il une langue de type sécurisé?

cette page http://golang.org/doc/go_faq.html écrit:

bien que Go ait des types statiques, le langage tente de rendre les types plus légers que dans les langages OO typiques

Donc ma question est exactement si elle est typée en toute sécurité avec des génériques (comme C #) ou vaguement typée (comme javascript) ou facultative (comme l'option stricte dans Vb.Net)

programming-languages algorithms google go type-safety Pacerier
la source

@JamesMcNellis signifie que si un type échoue, cela ne peut être que parce que je fais une conversion de type (toute autre action ne doit pas provoquer d'exception de type)

Pacerier

@ davidk01 Java va compiler (1 + "boo"), et le joli type de Java est sûr. Cette expression a une signification statique définie car le + est surchargé pour les objets String par le langage, et tous les littéraux primitifs peuvent être convertis en objets encapsulés qui peuvent ensuite être transformés en chaînes.

Trixie Wolf

Réponses:

La sécurité de type n'est pas un type sûr en noir ou blanc. C'est plus un spectre et certaines langues peuvent être plus sécuritaires que d'autres (et vice versa). Cependant, je pense que ce que vous pensez avec C # vs Javascript est probablement le typage statique (où la vérification de type se produit au moment de la compilation) vs le typage dynamique (où la vérification de type se produit au moment de l'exécution) - certainement, c'est de quoi parle la FAQ Go.

Google Go est tapé de façon statique, mais un certain nombre de fonctionnalités le font "sembler" être (au moins quelque peu) typé dynamiquement. Par exemple, vous n'avez pas besoin de marquer explicitement votre classe comme implémentant des interfaces. Si les signatures de méthode de votre classe correspondent à celles de l'interface, votre classe implémente automatiquement cette interface (une sorte de typage de canard). Ceci est utile pour étendre les classes intégrées et les classes dans des bibliothèques tierces, car vous pouvez simplement créer votre interface pour qu'elle corresponde aux méthodes de la classe tierce et elle l'implémentera automatiquement.

La sécurité de type est en fait un "axe" différent du système de type. Par exemple, C est un langage de type statique qui n'est pas sûr pour le type - les pointeurs vous permettent de faire à peu près tout ce que vous aimez, même des choses qui planteront votre programme. Javascript est typé dynamiquement, mais il est également sûr pour le type: vous ne pouvez pas effectuer d'opérations qui planteront votre programme. C # est principalement protégé par type, mais vous pouvez marquer explicitement les zones de code qui sont unsafeet faire des choses qui ne sont plus sécurisées par type.

Google Go est également protégé par type dans le sens où vous ne pouvez pas jouer avec les types et bloquer le programme (pas d'accès direct aux pointeurs).

Dean Harding
la source

A moins que vous n'utilisiez le paquet "unsafe", auquel cas vous pouvez planter le programme comme bon vous semble :)

Eloff

Vous pouvez jouer avec les types et avoir accès aux pointeurs. Et oui, vous pouvez facilement planter votre programme en faisant cela.

Il est tapé en toute sécurité dans la mesure où un type ne sera jamais mal interprété, mais un type incorrect peut provoquer la panique du programme.

dan_waterworth
la source

je ne comprends pas, cela signifie-t-il que du code sécurisé non-type peut être compilé? (ce qui n'est pas possible en c # sauf si nous utilisons la dynamique)

Pacerier

Faire des assertions de type, au niveau du type, revient à appeler une méthode sur un type dynamique

dan_waterworth

ok donc en bref, il n'a pas ce genre de sécurité de type c # permet?

Pacerier

C'est le cas si vous ne faites pas d'assertions de type.

dan_waterworth

@Pacerier: Il est parfaitement possible d'exécuter des expressions mal typées en C # sans dynamique: il suffit d'insérer des transtypages partout (ce qui est essentiellement ce que sont les assertions de type).

sepp2k

-1

Le type de carte de Go n'est pas thread-safe, il est typé statiquement. Il n'a pas d'héritage de type, de programmation générique, d'assertions, de surcharge de méthode ou d'arithmétique de pointeur non plus et pour une bonne raison.

La sécurité du type et la sécurité de la mémoire sont des objectifs à long terme, ici, c'est un problème.

La sécurité de type présente un surcoût, en kilo-octets et mégaoctets, ce qui est acceptable. Go est conçu avec MapReduce et "Big data", exobe un pétaoctet de données, ce qui présente des problèmes de performances avec la sécurité des types, la vérification de type (boxing / unboxing) crée des frais généraux et éloigne les cycles du traitement.

La sécurité de type peut être restrictive dans le sous-typage et le polymorphisme et dans le typage canard (cast objet à objet), cela crée des dangers et aussi un espace où les langages comme Go sont très utiles. C ++ et Java ne sont pas remplacés par Go, c'est un nouveau langage pour aider la programmation distribuée et le système massivement parallèle.

La grande déclaration de Bruce Eckel - "Go a beaucoup plus de sens pour la classe de problèmes que C ++ était initialement destiné à résoudre", est discutable. C ++ est un langage très efficace et l'implémentation Boost de MapReduce est très efficace.

Les primitives de concurrence sont l'avenir. La sécurité des caractères a toujours été un sujet très controversé et Go est peut-être la première langue à aborder ce problème depuis 20 ans, ou depuis Algol.

mrhassell
la source

Malheureusement, j'ai besoin de plus de réputation pour -1 cette réponse. La sécurité de type n'est pas un surcoût, le surcoût d'exécution n'est certainement pas mesuré en unités d'octets, et go a du boxing / unboxing au sens de Java. Le typage statique permet au compilateur de faire plus d’optimisations qu’un langage typé dynamiquement. La réduction de la carte n'est ni ici ni là-bas, idem avec la sécurité des threads.

Eloff

L'idiome de Golang de vous faire affirmer des types en utilisant une interface vide comme modèle commun pour éviter l'implémentation de génériques en tant que fonctionnalités de langage n'est certainement pas quelque chose que je considérerais comme "type sûr", et bien qu'il puisse garder la spécification de langue simple, lorsque le problème surgit (et il le fera), il laisse la complexité sur la plaque de la personne qui est maintenant laissée pour résoudre le problème avec le rouleau de robinet golang appelle une fonctionnalité. Cela ne ressemble certainement pas à un langage qui a été conçu au cours des 2 dernières décennies, car il existe des langages qui abordent la sécurité des types de manière bien meilleure.

tsturzl