Diskussion:Go (Programmiersprache)

Go ist in der Version 1.11 Verfügbar

Go ist am 24.08.2018 in der Version 1.11 erschienen. Kein Plan wie man das im Wiki ändert https://golang.org/doc/go1.11 und https://blog.golang.org/ wäre cool wenn das geändert wird

Geschweifte Klammern für Code-Blöcke

Im Artikel steht (z. Zt): "Code-Blöcke werden mit geschweiften Klammern abgegrenzt." Das stimmt so nur zum Teil, siehe Googles Beispiel dort: http://golang.org/doc/go_tutorial.html#tmp_17 Man kann/muss(?) Deklarationen mit runden Klammern einfassen.

sOT: wird eine Spannende Löschdiksussion geben: keine Quellen außerhalb des Netzes, nur eine Primärquelle ... ;-) Pinoccio 17:45, 11. Nov. 2009 (CET)

Hintergründe fehlen

Ein bisschen schwachbrüstig ist der Artikel schon noch. Warum wurde diese Programmiersprache erfunden? Wofür wird sie eingesetzt? Welche Vorteile bietet sie gegenüber anderen Programmiersprachen? --j ?! 21:34, 11. Nov. 2009 (CET)

Paradigma "kompilierbar"

Seit man ist "kompilierbar" ein Programmierparadigma? Oder anders gesagt: Was hindert mich daran, einen Interpreter für Go zu schreiben? --Novox 13:13, 15. Jan. 2010 (CET)

Sehe ich genauso: ist kein Paradigma. Hab auch auf die schnelle keine andere Sprache gefunden, bei der es angegeben wäre. Da seit Januar keiner geantwortet hat, werde ich es entfernen. Falls es andere Meinungen gibt, bitte hier begründen. --vwm 23:06, 25. Mär. 2010 (CET)

Das GO kompilierbar ist wird behauptet, nicht aber erklärt. Wenn man keine Ahnung von dem Thema hat, fällt das auf. ;) (nicht signierter Beitrag von 2A02:8109:ABBF:BCF4:9C5A:6F87:C475:7357 (Diskussion) 19:34, 22. Mai 2023 (CEST))

Go gab es vorher schon

das jemand anderes eine sprache namens "Go" lange vor Google entwickelt hatte fehlt auch komplett.. näheres dazu war in der google mailingliste zu finden (nicht signierter Beitrag von 77.180.197.131 (Diskussion | Beiträge) 19:11, 17. Jan. 2010 (CET))

Stimmt. In der englischen Wikipedia gibt es sowohl den Hinweis, wie auch die Programmiersprache. Go! existiert seit 2003.. --NiklasR 12:09, 05. Juni 2010 (CEST)

Ich habs mal hinzugefügt, fehlt nur noch die Sichtung (Ist in der englischen Wikipedia so auch drin.)--niklasR - In der Lust! 20:19, 6. Jun. 2010 (CEST)

unverständlich

Der Artikel könnte stellenweise etwas verständlicher geschrieben sein. --Gfrat 01:04, 17. Apr. 2010 (CEST)

• "Go bietet True Closures" - Was sind True Closures?
• "durch das Entwurfsmuster Mixin transparent realisiert" - Was bedeutet "transparent realisiert"?
• "Chaining" - Was bedeutet das? Bitte einen Beleg für die Existenz dieses Verfahrens.
• Was bedeutet "wird [...] zu statisch gelinktem Maschinencode kompiliert."?
• "um verwirrende Überschneidungen zwischen deren Zwecken zu vermeiden" - Was bedeutet dieser Satz?

Volle Zustimmung! Ein einziger Wust von Unverständlichkeiten! Oma-Test: zero points - Ich verstehe fast nichts, obwohl ich eigentlich vom Fach bin. Den "statisch gelinkten Maschinencode" kann ich mir nur so erklären, dass damit explizite Adressierungen gemeint sein könnten, insbesondere von Subroutinen. Aber ob es das ist? Keine Ahnung. -- Remirus 13:29, 20. Jul. 2010 (CEST)

Geht mir auch so, anscheinend sind da wild Buzz Words von Newsseiten zusammengesammelt worden. Mit "True Closures" sind einfach nur Closures gemeint. Es gibt schließlich genug Sprachen, die ein Closure-artiges Feature haben. So gesehen ist es eine Stärke von Go, dass es Closures voll unterstützt. Hab auch noch was hinzuzufügen: Embedding?! Ich nehme an, dass damit Interfaces gemeint sind, schließlich unterstützt Go wirklich keine Vererbung. Werd mich jetzt mal dranmachen die Punkte aus dem Weg zu räumen....

Zum Thema: "statisch gelinkten Maschinencode" Das ist Bullsh... Was der Mensch meinte war nativer Binärcode, der üblicherweise aber eher dynamisch gelinkt wird. Vermutlich wollte er es von Byte-Code-Sprachen abgrenzen. --hasta luego 16:05, 27. Okt. 2010 (CEST)

So, done. Gibt zwar sicher noch einiges zu tun, aber ich denke das der wesentliche Teil des Artikels jetzt einigermaßen Verständlich ist und von Falschaussagen befreit. --hasta luego 16:30, 27. Okt. 2010 (CEST)

Unbelegte Aussagen

• "Die automatische Speicherbereinigung soll praktisch verzögerungsfrei und mit nur minimalem zusätzlichem Rechenaufwand arbeiten"
• "Diese Effizienz soll sie mit der Benutzerfreundlichkeit einer dynamisch typisierten Sprache verbinden. Daher wurde auch bei den Sprachmitteln auf möglichst große Orthogonalität geachtet" - Bitte belegen, dass zur Verbesserung der Benutzerfreundlichkeit auf möglichst große Orthogonalität geachtet wurde.

Die obigen Aussagen bitte belegen. --Gfrat 01:13, 17. Apr. 2010 (CEST)

Das alles kann man auch auf der Website und den angegebenen Referenzen nachlesen. Aber ja, die Referenzen müssen sicher mal aufgeräumt werden. Aber das Rob Pike an der Sprache mitgearbeitet hat, sollte für Orthogonalität Beweis genug sein ;P --hasta luego 16:34, 27. Okt. 2010 (CEST)

Inhalte

Der Abschnitt "Merkmale, Sprachmittel" ist ein einziges Bullshit-Bingo. Ein paar ausführlichere Erklärungen, was denn bitte der Unterschied zu Objekten ist und WARUM bewusst auf eine Typhierarchie verzichtes wurde, wären durchaus angebracht. Auch die anderes Buzzwords wie "True Closures" sollten zumindest kurz angerissen werden. -- Krstfrs 04:19, 6. Jun. 2010 (CEST)

Jou! Stimmt. Und jetzt kommt die Preisfrage: Wer hat die Zeit und macht sich die Mühe, das Ganze zu überarbeiten ? -- Hawe 19:25, 27. Jul. 2010 (CEST)

Warum auf Typhierachie verzichtet wurde? Einfach mal nach "Inheritance considered harmful" suchen. Interessanterweise äußerte sich James Gosling auch schon kritisch über Vererbungshierarchien und ihre Probleme: http://zoomblab.blogspot.com/2009/11/james-gosling-must-be-loving-go.html. Jeder der schon mal komplexe Java-SW weiterentwickeln musste, weiß wie die Vererbungshölle dort aussieht: extends AbstractXYZFactory, implements BlaXYGenericInterface, ... über 7 Hierarchiestufen und man findet immer noch einen Entwickler der noch einen draufsetzt. Folgen: Schlechte Code Wartbarkeit + Over Engineering. Das sahen Pike und Co. offenbar auch so und haben sie rausgeworfen und durch implizite Schnittstellen + Type Embedding ersetzt. -- chr (nicht signierter Beitrag von 149.220.25.87 (Diskussion) 12:18, 11. Okt. 2011 (CEST))

Hallo zusammen, hab schon lange nicht mehr reingeschaut. Der Artikel ist ja inzwischen richtig gut geworden. Respekt! Und Dank an alle Beteiligten. --Hawe (Diskussion) 18:18, 18. Okt. 2014 (CEST)

Beispiele

Man sollte ein Beispiel einfügen, dass die Sprachbesonderheiten von Go besser demonstrieren. Der Echo Nachbau ist da nicht so gut geeignet. Was mit Channels und Goroutinen wäre besser. (nicht signierter Beitrag von 149.220.25.87 (Diskussion) 11:28, 11. Okt. 2011 (CEST))

done 178.12.10.214 02:08, 5. Mai 2013 (CEST)

Fragliche Inhalte

> "beide sollen Speicherbereinigung nach Vorbild von IBMs Recycler-Algorithmus[8] durch eine gemeinsame Laufzeitbibliothek erhalten, von der nur minimaler zusätzlicher Rechenaufwand erwartet wird"

Gibt es dazu eine Quelle? Ich kenne bisher nur http://golang.org/doc/go_faq.html#garbage_collection "The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach."

> "und benötigt ein Vielfaches an Kompilierzeit verglichen zu 6g"

Gibt es für "Vielfaches" eine Quelle? Langsamer, ja: http://blog.golang.org/2012/07/gccgo-in-gcc-471.html "Compared to gc, gccgo is slower to compile code but supports more powerful optimizations" Aber ein Vielfaches?

> "die auf Linux und Mac OS X betrieben werden können"

Windows ist seit Go 1 ebenfalls voll unterstützt: http://golang.org/doc/install#windows

--95.113.199.229 10:25, 2. Aug. 2012 (CEST)

(Keine!) Systemprogrammierung

Definition von Systemprogrammierung aus der Wikipedia Seite: "Als Systemprogrammierung bezeichnet man das Erstellen von Softwarekomponenten, die Teil des Betriebssystems sind oder die möglichst eng mit dem Betriebssystem bzw. mit der darunter liegenden Hardware kommunizieren müssen." Jeder, der sich schon mal mit der hardwarenahen Programmierung beschäftigt hat weiß, dass man dazu zwingendermaßen Sachen wie zB. Zeigerarithmetik benötigt. Und genau das bietet Go nicht. Die Schöpfer von Go bezeichnen die Sprache zwar als Sprache zur Systemprogrammierung, jedoch haben sie offensichtlich ihr eigene Definition für diesen Begriff. Was die Allgemeinheit unter Systemprogrammierung versteht kann Go objektiv betrachtet niemals leisten, denn es wurde nie dafür designt um Sachen wie Speicherverwaltung damit zu implementieren. Das Anwendungsgebiet für Go liegt in den höheren Schichten, nämlich in der Anwendungsschicht.

Ich schlage vor den Begriff Systemprogrammierung ganz aus dem Artikel zu streichen um keine Verwirrung beim Leser zu stiften. Zumindest aber sollte man in dem Artikel abgrenzen, was die Schöpfer von Go unter dem Begriff Systemprogrammierung verstehen und was der Unterschied zur allgemeinen Definition des Begriffs ist. (nicht signierter Beitrag von 188.174.50.106 (Diskussion) 15:51, 4. Aug. 2012 (CEST))

Rob Pike sagte in einem Interview [1]: "We designed it to be a systems level language because the problems we do at Google are systems level, right? Web servers and database systems, and storage systems and those are systems. Not operating systems, I don't know that Go would be a good operating system language but I am not sure it wouldn't be, what was interesting was because of the approach we took in the design of the language, somewhat to our surprise it turned out to be a really nice general purpose language."

Systemprogrammierung muss nicht im Kernel stattfinden. Go bietet übrigens auch ein System-Call-Package: http://golang.org/pkg/syscall/

--95.113.223.15 13:28, 5. Aug. 2012 (CEST)

Rob Pike definiert Systemprogrammierung im Kontext von Web server, Datenbanken und Speichersystemen weil dies auch Systeme seien. Mir ist klar, was Rob Pike damit meint. Ich finde es ist trotzdem irreführend für den Leser, da Systemprogrammierung eigentlich auch besonders die untersten Softwareschichten nahe dem Kernel und auch den Kernel selbst mit einschließt. Das System-Call Package von Go stellt so eine Schnittstelle zur Kernel API zur Verfügung, aber hardwarenahe Programmierung ist damit trotzdem nicht möglich.

Ich finde wenn wir den Begriff Systemprogrammierung verwenden, sollten wir das ganze Zitat von Rob Pike plus einer Erkläuterung direkt im Artikel einbauen. So treten dann auch keine Missverständisse auf. --ThomasWningr (Diskussion) 21:00, 5. Aug. 2012 (CEST)

Ich finde es ok einen anderen Begriff als "Systemprogrammierung" zu verwenden, aber den Begriff "Anwendungsentwicklung", wie er jetzt im Artikel steht, finde ich mindestens genauso fehlleitend. Vielleicht sollte man einfach nur "Softwareentwicklung" nehmen.

--217.190.103.122 18:10, 7. Aug. 2012 (CEST)

Bei Google geht es um die Entwicklung von Serversystemen. Vielleicht hilft hier das Wort "Systementwicklung" weiter. --Hawe (Diskussion) 22:28, 4. Sep. 2012 (CEST)

„unverständlicher Satz“

@Centenier: Wenn du den Satz nicht magst, kannst du ihn ja verständlicher machen. Aber die Änderung kannst du nicht einfach rückgängig machen, denn so, wie es im Artikel steht, ist der Satz falsch. – Gorlingor (Diskussion) 08:39, 10. Mai 2016 (CEST)

Ich bitte dich also darum, deine Änderung wieder rückgängig zu machen. – Gorlingor (Diskussion) 08:40, 10. Mai 2016 (CEST)

Die wikipedia verlangt, daß auch Leute „ohne die mindeste Ahnung“ verstehen was da geschrieben steht. Wenn Du das verstehst müssen das andere noch lange nicht. Aber im Grunde ist es mir der Sermon ohnehin wurscht -- Centenier (Diskussion) 08:43, 10. Mai 2016 (CEST)

Der Satz war schon vorher nicht OMA-tauglich, der unangemeldete Nutzer hat ihn bloß fachlich korrigiert. In solchen Fällen halte ich es für sinnvoller, einen Hinweis auf die Allgemeinverständlichkeit auf der Diskussionsseite oder als Baustein (Vorlage:Allgemeinverständlichkeit) direkt im betroffenen Abschnitt des Artikels zu hinterlassen. Danke fürs Zurücknehmen deiner Zurücksetzung. Viele Grüße – Gorlingor (Diskussion) 08:59, 10. Mai 2016 (CEST)

"Objektorientiert"?

Ich würde die Klassifizierung unter Pradigmen von GO als objektorientierte Sprache hinterfragen. Wie in der Sektion "Objektorientierung" in diesem Wikiartikel sehr schön aufgelistet, handelt es sich nicht um eine typische objektorientierte Programmiersprache. Auch auf der GO-Lang/FAQ Seite wird die Frage mit "Yes and No" (https://golang.org/doc/faq#Is_Go_an_object-oriented_language) beantwortet.

* Lösung A - analog zur englischsprachigen Version den Paradigmeneintrag einfach weglassen
* Lösung B - Das Paradigma in der Infobox zumindest unter Anführungszeichen setzen oder sonstwie relativieren. (nicht signierter Beitrag von 165.225.72.90 (Diskussion) 12:15, 27. Jul 2016 (CEST))

"Unterstützung von Nebenläufigkeit"

Weiss nicht, was damit gemeint ist. Könnte das jemand erklären? Danke. --Renek78 (Diskussion) 23:28, 19. Sep. 2018 (CEST)

Go Mixins

Zitat: "Statt Vererbung und Typ-Hierarchien kommt in Go Komposition zum Einsatz. Hierfür unterstützt Go eine Form von Mixins, die in Go embedding („Einbettung“) genannt wird: eine Datenstruktur kann beliebig viele andere Datentypen einbetten, so dass sie deren Methoden und Datenfelder erhält."

Was hat das ganze mit einem Mixin zu tun? Vielleicht sollte der Urheber mal die Wikipedia-Seite über Mixins lesen?! Es handelt sich dabei um wiederverwendbare Code-Bestandteile. Das einbetten anderer Klassen (aka structs in Go) ist aber nicht dasselbe wie ein Mixin.

Für gewöhnlich ist ein Mixin eine Funktionalität,die ich ein einziges mal implementieren muss und sie dann für beliebige Klassen verwenden kann. Hier kann ich es aber nicht für beliebige Klassen verwenden, sondern lediglich in andere Objekte einbinden. Dabei bekommt auch nicht das Objekt selber diese Methoden zugewiesen sondern das Unterobjekt selber behält natürlich die Methoden. Das ist nichts besonderes und beherrscht jede andere Sprache auch. Natürlich kann ich in einem struct eine struct definieren. Das ist aber KEIN MIXIN.

Nach der Definition würde selbst C++ Mixins unterstützen... Bitte herausnehmen oder Belege (andere als der Autor selber) liefern. --91.249.82.6 20:58, 13. Aug. 2019 (CEST)

> "Dabei bekommt auch nicht das Objekt selber diese Methoden zugewiesen sondern ..."

Das stimmt nicht. Beim Embedding in Go bekommt durchaus das äußere Objekt die Methoden der eingebetteten Structs zugewiesen:

type Springer struct {}
func (s Springer) Springe() { println("hüpf") }

type Fresser struct {}
func (f Fresser) Fresse() { println("mampf") }

type Känguru struct {
	Springer
	Fresser
}

func main() {
	k := Känguru{}
	k.Springe()
	k.Fresse()
}

--Stephen Dedalus (Diskussion) 12:54, 20. Jan. 2020 (CET)

Beispiel nicht in Go-Syntax

Das hier ist doch keine Go-Syntax:

if(integer_pointer != nil)    /* Wenn zutreffend Zeiger Variable speichert einen Zeiger auf einen Speicherbereich */
if(integer_pointer == nil)    /* Wenn zutreffend Zeiger Variable speichert keinen Zeiger auf einen Speicherbereich */

Syntaktisch und verstaendlich besser faende ich es so:

if integer_pointer != nil {
    /* Zeiger-Variable speichert einen Zeiger auf einen Speicherbereich */
}
if integer_pointer == nil {
    /* Zeiger-Variable ist leer */
}

... bloss bin ich kein Go-Programmierer, so dass ich nicht sagen kann, ob das wirklich korrekt ist. Wenn das korrekte Go-Syntax ist, dann bitte uebernehmen. --Meillo (Diskussion) 09:03, 21. Okt. 2021 (CEST)