Diskussion:Go (Programmiersprache)

message: 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)
thread_title:  Geschweifte Klammern für Code-Blöcke 

message: 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)
thread_title:  Hintergründe fehlen 

message: 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)
replies: text: 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)
thread_title:  Paradigma "kompilierbar" 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Go gab es vorher schon 

message: * "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)
replies: text: 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)
thread_title:  Unbelegte Aussagen 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Inhalte 

message: 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)
thread_title:  Beispiele 

message: > "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)
thread_title:  Fragliche Inhalte 

message: @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)
replies: text: Ich bitte dich also darum, deine Änderung wieder rückgängig zu machen. – Gorlingor (Diskussion) 08:40, 10. Mai 2016 (CEST)
replies: text: 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)
replies: text: 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)
thread_title:  „unverständlicher Satz“ 

message: 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)
thread_title:  "Objektorientiert"? 

message: Weiss nicht, was damit gemeint ist. Könnte das jemand erklären? Danke. --Renek78 (Diskussion) 23:28, 19. Sep. 2018 (CEST)
thread_title:  "Unterstützung von Nebenläufigkeit" 

message: 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)
thread_title:  Beispiel nicht in Go-Syntax