Ist Googles eine typsichere Sprache?

Diese Seite http://golang.org/doc/go_faq.html schreibt:

Obwohl Go statische Typen hat, versucht die Sprache, dass sich die Typen leichter anfühlen als in typischen OO-Sprachen

Also meine Frage ist genau, ob es sicher mit Generika (wie C #) oder lose (wie Javascript) oder optional (wie Option streng in Vb.Net) getippt ist.

— Pacerier
quelle

@JamesMcNellis bedeutet, wenn ein Typ ausfällt, kann es nur sein, weil ich einen Typ-Cast mache (jede andere Aktion sollte keine Typ-Ausnahme verursachen)

— Pacerier

@ davidk01 Java kompiliert (1 + "boo") und Java ist ziemlich typsicher. Dieser Ausdruck hat eine bestimmte statische Bedeutung, da + für String-Objekte von der Sprache überladen ist und alle primitiven Literale in umgebrochene Objekte umgewandelt werden können, die dann in Strings umgewandelt werden können.

— Trixie Wolf

Antworten:

Typensicherheit ist kein schwarz-weißer Typensafe oder nicht. Es ist eher ein Spektrum und einige Sprachen können mehr Art sicher als andere (und umgekehrt). Ich denke jedoch, was Sie mit C # im Vergleich zu Javascript denken, ist wahrscheinlich statische Typisierung (bei der die Typprüfung zur Kompilierungszeit stattfindet) im Vergleich zu dynamischer Typisierung (bei der die Typprüfung zur Laufzeit stattfindet) Worüber die Go FAQ spricht.

Google Go ist statisch geschrieben, aber eine Reihe von Funktionen lassen es (zumindest etwas) dynamisch erscheinen. Beispielsweise müssen Sie Ihre Klasse nicht explizit als Implementierung von Schnittstellen kennzeichnen. Wenn die Methodensignaturen Ihrer Klasse mit denen auf der Schnittstelle übereinstimmen, implementiert Ihre Klasse diese Schnittstelle automatisch (eine Art Duck-Typing). Dies ist nützlich, um integrierte Klassen und Klassen in Bibliotheken von Drittanbietern zu erweitern, da Sie Ihre Schnittstelle einfach so einrichten können, dass sie mit den Methoden der Klasse von Drittanbietern übereinstimmt, und diese automatisch implementiert.

Die Typensicherheit ist eigentlich eine andere "Achse" des Typensystems. Zum Beispiel ist C eine statisch typisierte Sprache, die nicht typsicher ist. Mit Zeigern können Sie so ziemlich alles tun, was Sie wollen, auch Dinge, die Ihr Programm zum Absturz bringen. Javascript wird dynamisch eingegeben, ist aber auch typsicher: Sie können keine Vorgänge ausführen, die zum Absturz Ihres Programms führen. C # ist größtenteils typsicher, aber Sie können explizit Codebereiche markieren, unsafedie nicht mehr typsicher sind, und Aktionen ausführen, die nicht mehr typsicher sind.

Google Go ist auch in dem Sinne typsicher, dass Sie nicht mit Typen herumspielen und das Programm zum Absturz bringen können (kein direkter Zugriff auf Zeiger).

— Dean Harding
quelle

Es sei denn, Sie verwenden das "unsichere" Paket. In diesem Fall können Sie das Programm nach

— Belieben zum

Sie können mit Typen herumspielen und haben Zugriff auf Zeiger. Und ja, Sie können Ihr Programm auf diese Weise leicht zum Absturz bringen.

— Zehnte

Es ist sicher geschrieben, dass ein Typ niemals falsch interpretiert wird, aber ein falscher Typ kann das Programm in Panik versetzen.

— dan_waterworth
quelle

Ich verstehe es nicht, bedeutet es, dass nicht typisierter sicherer Code tatsächlich kompiliert werden kann? (was in c # nur möglich ist, wenn wir Dynamik verwenden)

— Pacerier

Das

— typmäßige Ausführen von Typzusicherungen entspricht im

ok, also kurz gesagt, es gibt nicht die Art von Sicherheit, die c # erlaubt?

— Pacerier

Dies ist der Fall, wenn Sie keine Zusicherungen eingeben.

— dan_waterworth

@Pacerier: Es ist durchaus möglich, fehlerhafte Ausdrücke in C # ohne Dynamik auszuführen: Fügen Sie einfach überall Casts ein (was im Grunde genommen die Typzusicherungen sind).

— 20.

-1

Go's Kartentyp ist nicht threadsicher, sondern statisch typisiert. Es ist nicht Art Vererbung, generische Programmierung, Assertions, Methodenüberladung oder Pointer - Arithmetik haben entweder aus gutem Grund.

Typensicherheit und Speichersicherheit sind langfristige Ziele, hier liegt ein Problem.

Die Typensicherheit verursacht einen akzeptablen Overhead in Kilobyte und Megabyte. Go wurde mit MapReduce und "Big Data" entwickelt, exobytes und petabytes von Daten, die Leistungsprobleme in Bezug auf die Typensicherheit darstellen. Die Typenkontrolle (Ein- und Auspacken) verursacht Overheads und entlastet die Verarbeitung.

Die Schriftsicherheit kann beim Untertippen und beim Polymorphismus sowie beim Eingeben von Enten (von Objekt zu Objekt geworfen) einschränkend sein. Dies schafft Gefahren und schafft einen Raum, in dem Sprachen wie Go von großem Nutzen sind. C ++ und Java werden nicht durch Go ersetzt. Es handelt sich um eine neue Sprache zur Unterstützung der verteilten Programmierung und des massiv parallelen Systems.

Die große Aussage von Bruce Eckel - "Go ist viel sinnvoller für die Klasse von Problemen, die C ++ ursprünglich lösen sollte", ist umstritten. C ++ ist eine sehr effiziente Sprache und die Boost-Implementierung von MapReduce ist sehr effizient.

Nebenläufigkeitsprimitive sind die Zukunft. Typensicherheit war schon immer ein sehr umstrittenes Thema und Go ist möglicherweise die erste Sprache, die sich seit 20 Jahren oder seit Algol mit diesem Thema befasst.

— mrhassell
quelle

Leider brauche ich mehr Reputation, um diese Antwort zu erhalten. Die Typensicherheit ist kein Overhead, der Laufzeit-Overhead wird definitiv nicht in Byte-Einheiten gemessen, und go hat Boxing / Unboxing im Java-Sinne. Durch die statische Typisierung kann der Compiler mehr Optimierungen vornehmen, als dies bei einer dynamisch getippten Sprache möglich ist. Kartenreduzierung gibt es weder hier noch dort, ebenso bei Thread-Sicherheit.

— Eloff

Golangs Redewendung, dass Sie Typen behaupten, die eine leere Schnittstelle als gemeinsames Muster verwenden, um die Implementierung von Generika als Sprachfeatures zu vermeiden, würde ich sicherlich nicht als "typensicher" erachten, und obwohl dies die Sprachspezifikation einfach halten könnte, wenn das Problem auftritt entsteht (und es wird) es bleibt die Komplexität auf dem Teller der Person, die jetzt übrig ist, um das Problem mit der Rolle des Leitungshahns zu lösen Golang nennt ein Merkmal. Es scheint mit Sicherheit keine Sprache zu sein, die in den letzten zwei Jahrzehnten entwickelt wurde, da es Sprachen gibt, die sich viel besser mit der Typensicherheit befassen.

— tsturzl