FAQ - Why are you creating a new language?

[Siciliano]

Go was born out of frustration with existing languages and environments for systems programming. Programming had become too difficult and the choice of languages was partly to blame. One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language. Programmers who could were choosing ease over safety and efficiency by moving to dynamically typed languages such as Python and JavaScript rather than C++ or, to a lesser extent, Java.

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer. To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection; rigid dependency specification; and so on. These cannot be addressed well by libraries or tools; a new language was called for.

http://golang.org/doc/go_faq.html#creating_a_new_language

[Anonymer Nutzer]

Also, wenn ich das richtig lese, dann steht da, dass Java viel zu komplex ist und deshalb viele Java Script benutzen??

Aus dem Text geht nicht hervor, ob es jetzt interpretiert wird, oder ob sowas wie bei Java vorliegt.

Die Sprache Unterstützt Netzwerkfunktionen und Multicore Support. Ja Wahsinn! Willkommen im 21. Jahrhundert.

Ich werd aus den Zeilen wirklich nicht schlau, wieso ich zukünftig diese Sprache verwenden sollte.

[natasha]

HerrMannelig schrieb:
--------------------------------------------------------------------------------
> Aus dem Text geht nicht hervor, ob es jetzt interpretiert wird, oder ob
> sowas wie bei Java vorliegt.

Der Code wird zu einem Maschinencode-Binary kompiliert, so wie bei C.

[dernop]

Ein neuer Standard muss her: http://xkcd.com/927/ !

[JOnathanJOnes]

natasha schrieb:
--------------------------------------------------------------------------------
> HerrMannelig schrieb:
> ---------------------------------------------------------------------------
> -----
> > Aus dem Text geht nicht hervor, ob es jetzt interpretiert wird, oder ob
> > sowas wie bei Java vorliegt.
>
> Der Code wird zu einem Maschinencode-Binary kompiliert, so wie bei C.

Und Java wird in Bytecode der VM kompelliert, was im grunde auch maschinencode ist (machinencode für die VM).

[Anonymer Nutzer]

Das ist aber kein echter Maschinencode. Es muss eben erst von der VM verarbeitet werden und jede zusätzliche Verarbeitung ist eben zusätzlicher Zeitaufwand.

Ich frage mich aber, was das dann mit der "Einfachheit von interpretierten Sprachen" zu tun hat, wie es da im FAQ steht. Seh da keinen Zusammenhang. Es muss programmiert und kompiliert werden, wie bei C# oder sonstwo auch..

[Dr. Pest]

Die Sprache ist im Vergleich zu etwa C# sehr simpel und leicht zu erlernen. Früher habe ich viel mit .NET gearbeitet (mit pre 1.0 bis 2.0). Vor einiger Zeit wollte ich mal sehen, was sich dort so getan hat, aber es war mir nach meinen Erfahrungen mit der Einfachheit von Go ein Graus, mich wieder mit dem Bloat von C# und Visual Studio herumzuplagen.

Die primären Implementierungen (gc, gccgo) kompilieren zu Maschinencode. Es wird auf Endbenutzerseite keine Installation benötigt, im Gegensatz zu den aufgeblasenen Runtimes von Java und .NET. Es reicht also im einfachsten Fall, die Programmdatei auf den Zielrechner zu kopieren. (Ein Segen für jeden, der Software nicht nur entwickeln muss, sondern auch für Setup und Support zuständig ist. Ich habe Go bisher hauptsächlich für Windows GUI Clients verwendet.)

Es kompiliert schneller als Java oder C#, Programme benötigen zur Laufzeit i.d.R. weniger Arbeitsspeicher, starten schneller und werden meist auch schneller ausgeführt.

Die Standardlibrary bietet einen reichhaltigen Satz an Funktionalität, ohne aufgeblasen zu wirken. Wenn ich da nur an Java oder .NET denke...
Wenn mehr benötigt wird, sind Thirdparty-Libs mit dem go tool bequem zu installieren.

Das sollte erst mal reichen.

[brat]

Du hast viel zu C# und Java geschrieben, was mich eher interessieren würde ist der vorteil gegenüber c/c++. Nur weils schneller kompiliert wird kaum einer umsteigen.

[doctorseus]

Für Leute die sich das Erlernen von C / C++ noch nicht angetan haben(oder nur teilweise) und für diejenigen für die schnelles effizientes Entwickeln mit schnellen Ergebnissen wichtig ist?

[Dr. Pest]

Betriebssysteme oder Gerätetreiber wirst Du mit Go nicht unbedingt schreiben können. Was Entwicklung mit C++ angeht, habe ich ab der Freigabe unter der LGPL etwa zwei Jahre mit Qt gearbeitet. Das fand ich im Vergleich zu .NET auch schon ziemlich angenehm, weil sich Qt, ähnlich wie Go, auf das Wesentliche beschränkt und man nicht von hunderten Methoden etc pro Klasse erschlagen wird. Bessere Performance-Charakteristiken für GUI-Apps, Cross-Plattform-Support und der freie-Software-Gedanke von Qt haben mich auch nicht zu .NET zurückblicken lassen.

Aber so toll Qt auch ist, C++ ist keine angenehme Sprache und mit Go ist vieles deutlich einfacher, ich bin damit jedenfalls produktiver und zufriedener mit meiner Arbeit. Wenn ich alleine an die Kompilier- und Linkorgien und Fehlermeldungen mit C++ zurückdenke läuft es mir eiskalt den Rücken runter. Mit Go bekommst Du dann halt auch noch (fast) alles aus einer Hand: Compiler, Build- und Paket-Tool, saubere Doku, umfassende aber nicht überfrachtete Standardlibrary.

Ich denke es lohnt sich einen genaueren Blick zu riskieren...

[GiveUsMcNeal!]

Ich wuerde schnellere compilierzeiten schon fast als ausreichendes argument sehen wenn ich meine 1-2min incremental builds so anschaue wenn ich nur ein .cpp file aendere (komplett rebuild etwa 10min). Und ich vermute mal jeder, der laengere zeit mit c++ programmiert, wird sich an gewissen punkten ueber die sprache aufregen.

Was mich hier konkret interessieren wuerde ist die performance im numerischen bereich. Kriegt go aehnlich flotten code zum number crunchen hin wie c++? Gibt es eventuell sogar vektoren als primitive? das waere schoen!

Ein anderer Punkt der sich schwer fassen laesst: ist go in sich konsistent? c++ ist ja mehr ein sammelsorium von ideen die relativ undurchdacht in ein sprache gepresst wurden. Ist go in diesem punkt sauberer designed?

und, als c++ programmierer ganz wichtig: gibt es in go einen echten string datentyp? :-)

[Dr. Pest]

Was die Numbercrunch-Performance angeht, kann ich aus eigener Erfahrung (noch) keine allzu fundierte Aussage machen. Es sollte jedenfalls nicht um Welten schlechter sein als C/C++. Vektoren gibt es nicht als Primitive. Es gibt aber als Primitive u.a. Slices [1], Maps [2] und Strings [3], die alle sehr angenehm zu verwenden sind.

Go beschränkt sich auf das Wichtigste, ohne dass ich das Gefühl habe, es fehlte etwas. Dadurch ist es realistisch die komplette Sprache im Kopf zu behalten und auch zu nutzen, nicht nur ein Subset davon, wie mit C++ oft zu sehen ist. Die Features arbeiten gut miteinander zusammen und zwingen einen schon fast dazu guten Code zu schreiben, der auch leicht lesbar und verständlich ist.

Ich bin jedenfalls sehr froh dass es Go gibt und verwende es seit Jahren überall wo es möglich ist.

[1] http://golang.org/ref/spec#Slice_types
[2] http://golang.org/ref/spec#Map_types
[3] http://golang.org/ref/spec#String_types

[renegade334]

Dr. Pest schrieb:
--------------------------------------------------------------------------------
> Die primären Implementierungen (gc, gccgo) kompilieren zu Maschinencode. Es
> wird auf Endbenutzerseite keine Installation benötigt, im Gegensatz zu den
> aufgeblasenen Runtimes von Java und .NET. Es reicht also im einfachsten
> Fall, die Programmdatei auf den Zielrechner zu kopieren.
Ich denke, dass die JRE nicht "aufgeblasen" ist. Als Download schon mal einzig die 20MB. Also wenn ich an .NET denke, dann muss man zig Hunderte runterladen, gebe ich dir absolut Recht. Weiß aber nicht, ob es reicht, nur .NET4 zu installieren, wenn ein Programm eines .NET1-3 braucht. Falls doch, dann gebe ich dir das "Aufgeblasenheit" Recht.

[Dr. Pest]

Naja es macht halt auch schon einen Unterschied, ob ich eine 2 MB .msi Datei für ein ~20KLOC Programm zum Download anbieten kann, oder eben den 20 MB JRE Installer mit reinpacken muss.

[GiveUsMcNeal!]

Dr. Pest schrieb:
--------------------------------------------------------------------------------
> Was die Numbercrunch-Performance angeht, kann ich aus eigener Erfahrung
> (noch) keine allzu fundierte Aussage machen. Es sollte jedenfalls nicht um
> Welten schlechter sein als C/C++. Vektoren gibt es nicht als Primitive. Es
> gibt aber als Primitive u.a. Slices [1], Maps [2] und Strings [3], die alle
> sehr angenehm zu verwenden sind.
>
> Go beschränkt sich auf das Wichtigste, ohne dass ich das Gefühl habe, es
> fehlte etwas. Dadurch ist es realistisch die komplette Sprache im Kopf zu
> behalten und auch zu nutzen, nicht nur ein Subset davon, wie mit C++ oft zu
> sehen ist. Die Features arbeiten gut miteinander zusammen und zwingen einen
> schon fast dazu guten Code zu schreiben, der auch leicht lesbar und
> verständlich ist.
>
> Ich bin jedenfalls sehr froh dass es Go gibt und verwende es seit Jahren
> überall wo es möglich ist.
>
> [1] golang.org#Slice_types
> [2] golang.org#Map_types
> [3] golang.org#String_types

Vielen Dank!

[SSD]

Dr. Pest schrieb:
--------------------------------------------------------------------------------
> Die primären Implementierungen (gc, gccgo) kompilieren zu Maschinencode. Es
> wird auf Endbenutzerseite keine Installation benötigt, im Gegensatz zu den
> aufgeblasenen Runtimes von Java und .NET. Es reicht also im einfachsten
> Fall, die Programmdatei auf den Zielrechner zu kopieren. (Ein Segen für
> jeden, der Software nicht nur entwickeln muss, sondern auch für Setup und
> Support zuständig ist. Ich habe Go bisher hauptsächlich für Windows GUI
> Clients verwendet.)
welches Framework?

Dr. Pest schrieb:
--------------------------------------------------------------------------------
> Aber so toll Qt auch ist, C++ ist keine angenehme Sprache
Wieso?

> und mit Go ist
> vieles deutlich einfacher, ich bin damit jedenfalls produktiver und
> zufriedener mit meiner Arbeit.
> Wenn ich alleine an die Kompilier- und
> Linkorgien und Fehlermeldungen mit C++ zurückdenke läuft es mir eiskalt den
> Rücken runter.
Was ist da bei Go besser?

> Mit Go bekommst Du dann halt auch noch (fast) alles aus
> einer Hand: Compiler, Build- und Paket-Tool, saubere Doku, umfassende aber
> nicht überfrachtete Standardlibrary.
Und wieso nimmt man nicht einfach ne IDE?

GiveUsMcNeal! schrieb:
--------------------------------------------------------------------------------
> und, als c++ programmierer ganz wichtig: gibt es in go einen echten string
> datentyp? :-)
Wieso ist der in C++ nicht echt?

[Dr. Pest]

Bin erst jetzt nochmal über diesen Artikel gestolpert, somit kommt die Antwort etwas spät :p

SSD schrieb:
--------------------------------------------------------------------------------
> Dr. Pest schrieb:
> ---------------------------------------------------------------------------
> -----
> > Die primären Implementierungen (gc, gccgo) kompilieren zu Maschinencode.
> Es
> > wird auf Endbenutzerseite keine Installation benötigt, im Gegensatz zu
> den
> > aufgeblasenen Runtimes von Java und .NET. Es reicht also im einfachsten
> > Fall, die Programmdatei auf den Zielrechner zu kopieren. (Ein Segen für
> > jeden, der Software nicht nur entwickeln muss, sondern auch für Setup
> und
> > Support zuständig ist. Ich habe Go bisher hauptsächlich für Windows GUI
> > Clients verwendet.)
> welches Framework?

Habe mit Unterstützung einiger freundlicher Leute selbst eins gemacht:
https://github.com/lxn/walk
Hauptinspiration u.a. für das Layoutsystem war Qt. Mit dem Tool ui2walk können die ui-Dateien benutzt werden, die der Qt Designer ausspuckt.

>
> Dr. Pest schrieb:
> ---------------------------------------------------------------------------
> -----
> > Aber so toll Qt auch ist, C++ ist keine angenehme Sprache
> Wieso?

Disclaimer: habe noch nicht mit C++11 gearbeitet
Was mir auf Anhieb einfällt:
- Kompliziert durch zu viele Features, niemand verwendet das selbe C++
- Für die meisten Anwendungen zu sehr auf Performance ausgerichtet, Einfachheit und Speichersicherheit erst an zweiter Stelle
- Build dauert sehr lang weil C++ kein Modulsystem hat
- Kryptische Fehlermeldungen von Compiler und Linker
- Kleine und mäßig hilfreiche Standardlibrary
- Schlechte Unterstützung für Concurrency
- Keine Stacktraces bei Crashes

>
> > und mit Go ist
> > vieles deutlich einfacher, ich bin damit jedenfalls produktiver und
> > zufriedener mit meiner Arbeit.
> > Wenn ich alleine an die Kompilier- und
> > Linkorgien und Fehlermeldungen mit C++ zurückdenke läuft es mir eiskalt
> den
> > Rücken runter.
> Was ist da bei Go besser?

U.a. alle oben angeführten Punkte.

>
> > Mit Go bekommst Du dann halt auch noch (fast) alles aus
> > einer Hand: Compiler, Build- und Paket-Tool, saubere Doku, umfassende
> aber
> > nicht überfrachtete Standardlibrary.
> Und wieso nimmt man nicht einfach ne IDE?

Viele Entwickler möchten oder können aus verschiedensten Gründen nicht mit einer IDE arbeiten. Eine IDE kann auch nicht alle schlechten Merkmale einer Programmiersprache und ihres Ökosystems kaschieren.

>
> GiveUsMcNeal! schrieb:
> ---------------------------------------------------------------------------
> -----
> > und, als c++ programmierer ganz wichtig: gibt es in go einen echten
> string
> > datentyp? :-)
> Wieso ist der in C++ nicht echt?

Es ist halt "nur" ein x-beliebiger Library-Typ ohne direkte Sprachunterstützung. Schau Dich mal um, viele Projekte ziehen es vor einen eigenen String-Typ zu verwenden. Warum ist das so, wenn std::string doch so toll ist?

[SSD]

Dr. Pest schrieb:
--------------------------------------------------------------------------------
> Bin erst jetzt nochmal über diesen Artikel gestolpert, somit kommt die
> Antwort etwas spät :p
Macht nichts :D
Du musst wissen, dass ich mich wirklich sehr freue, dass du mir noch zurück geschrieben hast, weil mich das Thema ziemlich interessiert.

> > welches Framework?
>
> Habe mit Unterstützung einiger freundlicher Leute selbst eins gemacht:
> github.com
> Hauptinspiration u.a. für das Layoutsystem war Qt. Mit dem Tool ui2walk
> können die ui-Dateien benutzt werden, die der Qt Designer ausspuckt.
Klingt interessant!
Ist die Bibliothek denn plattformunabhängig und wenn nicht, wieso nicht (ich nehme aufgrund des Namens an, dass es nicht so ist). Wieso wäre an der Stelle ein einfaches Binding nicht besser gewesen und - ungefähr - zu wie viel % werden die Elemente von den ui-Dateien unterstützt?

> > > Aber so toll Qt auch ist, C++ ist keine angenehme Sprache
> > Wieso?
>
> Disclaimer: habe noch nicht mit C++11 gearbeitet
> Was mir auf Anhieb einfällt:
> - Kompliziert durch zu viele Features, niemand verwendet das selbe C++
Java und C# haben auch viele Features; ist das bei den beiden auch schlecht?
Die Frage ist doch viel mehr, wie sinnvoll die Features sind, oder nicht?
Weiters können viele "Features" doch gar nicht "nervig" sein (z.B. das Überladen von Operatoren).
Daher stellt sich schlussendlich die Frage, welche Features "nervig" UND "sinnlos" sind. Kannst du mir da ein paar aufzählen?

> - Für die meisten Anwendungen zu sehr auf Performance ausgerichtet,
> Einfachheit und Speichersicherheit erst an zweiter Stelle
Es gibt zwar keine herkömmliche Garbage Collection, dafür aber GC je Pointer / auf Objektbasis
-> Smart Pointer: in C++ std::auto_ptr und in C++11 zusätzlich std::unique_ptr, std::shared_ptr und std::weak_ptr
afaik entspricht ein unique_ptr einem auto_ptr, womit dieser obsolete wird
Dieses GC-System (von C++) ist zwar nicht ganz so einfach wie ein herkömmliches, dafür ist es aber weit flexibler und effizienter. Es wird genauso wie in Goo keine Laufzeitumgebung benötigt und ist daher relativ effizient, wobei C++ wohl noch ein bisschen effizienter sein dürfte als Goo. Zusätzlich kann bei kritischen Stellen (hohe Performance benötigt) die Speicherverwaltung selbst übernommen werden, womit in C++ keine Notwendigkeit besteht, für Performance-kritische Anwendungen Bindings zu verwenden, wie sonst üblich.
Wie sieht es aber außerhalb der GC aus? - in welchen Bereichen ist Goo wirklich einfacher?
einer fällt mir selbst ein: Aufbau eines string aus nicht-string Typen
Aber sonst?

> - Build dauert sehr lang weil C++ kein Modulsystem hat
Klassen und Funktionen können in Namespaces verpackt werden, was dann so eine Art Modul ist.
Du sprichst etwas an, das ich gerne wüsste:
Wie schafft es Goo eigentlich, so eine niedrige Kompilierzeit zu erreichen?

> - Kryptische Fehlermeldungen von Compiler und Linker
Das stimmt wohl, ist aber auch teilweise Compilerabhängig.
Es ist aber wohl auch nur Gewohnheitssache und die SA (Syntax Analysis) einer IDE kann einem dabei das Leben auch stark vereinfachen.

> - Kleine und mäßig hilfreiche Standardlibrary
Das stimmt wohl auch, wird auch durch C++11 etwas verbessert, aber wie sieht es da bei Goo aus?
Also GUI-Support gibt es ja nicht, sonst hättet ihr ja die vorhandene Funktionalität genommen, oder?
Wie sieht es mit Netzwerk, Multimedia und Kommunikation aus?

> - Schlechte Unterstützung für Concurrency
In normalem C++ afaik gar keine Unterstützung, mit C++11 kommt jedoch vollständige Unterstützung hinzu.

Das könnte dann z.B. so aussehen:
#include <iostream>
#include <vector>
#include <thread>
#include <mutex>
using namespace std;

mutex m;
void func(int n) {
lock_guard<mutex> lk(m);
cout << "Launched by thread " << n << endl;
}

int main() {
int n = 10; // number of threads

//Launch a group of threads
vector<thread> th;
for (int i = 0; i < n; ++i)
th.push_back(thread(func, i));

//Join the threads with the main thread
for (auto &t : th)
t.join();

return 0;
}
(heute funktionsfähiger Code mit einem Standard-Compiler)

> - Keine Stacktraces bei Crashes
Auch ein Punkt, der stimmt, aber durch eine IDE mit Debugger, denke ich, nicht so schlimm ist.

> > > Mit Go bekommst Du dann halt auch noch (fast) alles aus
> > > einer Hand: Compiler, Build- und Paket-Tool, saubere Doku, umfassende
> > aber
> > > nicht überfrachtete Standardlibrary.
> > Und wieso nimmt man nicht einfach ne IDE?
>
> Viele Entwickler möchten oder können aus verschiedensten Gründen nicht mit
> einer IDE arbeiten.
Die da wären?
Bei Skriptsprachen verstehe ich das ja noch, aber wenn der Quelltext ja sowieso kompiliert werden muss ...
Außerdem ist mit einer IDE Rafactoring, Projektverwaltung und Kollaboration doch viel einfacher, nicht?

> Eine IDE kann auch nicht alle schlechten Merkmale einer
> Programmiersprache und ihres Ökosystems kaschieren.
Klar.

> > > und, als c++ programmierer ganz wichtig: gibt es in go einen echten
> > string
> > > datentyp? :-)
> > Wieso ist der in C++ nicht echt?
>
> Es ist halt "nur" ein x-beliebiger Library-Typ ohne direkte
> Sprachunterstützung. Schau Dich mal um, viele Projekte ziehen es vor einen
> eigenen String-Typ zu verwenden. Warum ist das so, wenn std::string doch so
> toll ist?
Wie ich schon (oben) erwähnt habe, ist std::string sicher nicht perfekt, aber wie kann denn ein eigener string-Typ besser sein?
Tut mir leid, ich bin noch nicht so ein erfahrener C++-Entwickler und kenne auch keine Projekte, die einen eigenen String-Typ verwenden.
Bis auf (den bereits erwähnten) Aufbau eines strings und das Parsen zu anderen Datentypen, das beides vll. nicht so intuitiv sind, fällt mir jetzt nichts spontan ein.

[Dr. Pest]

SSD schrieb:
--------------------------------------------------------------------------------
> Dr. Pest schrieb:
> ---------------------------------------------------------------------------
> -----
> > Bin erst jetzt nochmal über diesen Artikel gestolpert, somit kommt die
> > Antwort etwas spät :p
> Macht nichts :D
> Du musst wissen, dass ich mich wirklich sehr freue, dass du mir noch zurück
> geschrieben hast, weil mich das Thema ziemlich interessiert.
>
> > > welches Framework?
> >
> > Habe mit Unterstützung einiger freundlicher Leute selbst eins gemacht:
> > github.com
> > Hauptinspiration u.a. für das Layoutsystem war Qt. Mit dem Tool ui2walk
> > können die ui-Dateien benutzt werden, die der Qt Designer ausspuckt.
> Klingt interessant!
> Ist die Bibliothek denn plattformunabhängig und wenn nicht, wieso nicht
> (ich nehme aufgrund des Namens an, dass es nicht so ist). Wieso wäre an der
> Stelle ein einfaches Binding nicht besser gewesen und - ungefähr - zu wie
> viel % werden die Elemente von den ui-Dateien unterstützt?

Windows only. Der Aufwand wäre sonst viel zu hoch gewesen und ich hätte nicht das Go (scnr) dafür bekommen. Es gibt aber auch diverse Bindings, siehe [1] und [2]. Kürzlich ist in der Go-Community die Diskussion um ein in Go geschriebenes Cross-Plattform GUI Toolkit wieder aufgekommen und jemand hat ein Projekt [3] gestartet.

Das ui2walk-Tool setzt folgende Elemente um:
QHBoxLayout -> BoxLayout
QVBoxLayout -> BoxLayout
QGridLayout -> GridLayout
QSpacer -> Spacer
QCheckBox -> CheckBox
QComboBox -> ComboBox
QDateEdit -> DateEdit
QDoubleSpinBox, QSpinBox -> NumberEdit
QFrame -> Composite
QGroupBox -> GroupBox
QLabel -> Label
QLineEdit -> LineEdit
QPlainTextEdit, QTextEdit -> TextEdit
QProgressBar -> ProgressBar
QPushButton, QToolButton -> PushButton
QRadioButton -> RadioButton
QSplitter -> Splitter
QTabWidget -> TabWidget
QTableView, QTableWidget -> TableView
QTreeView, QTreeWidget -> TreeView
QWebView -> WebView
QWidget -> Composite | TabPage

Nicht alle Properties werden umgesetzt, aber die Wichtigsten werden unterstützt.

> > > > Aber so toll Qt auch ist, C++ ist keine angenehme Sprache
> > > Wieso?
> >
> > Disclaimer: habe noch nicht mit C++11 gearbeitet
> > Was mir auf Anhieb einfällt:
> > - Kompliziert durch zu viele Features, niemand verwendet das selbe C++
> Java und C# haben auch viele Features; ist das bei den beiden auch
> schlecht?

Zu Java kann ich nicht viel sagen, hatte zuletzt vor etwa zehn Jahren das "Vergnügen". Aber auch C# ist im Vergleich zu Go meines Erachtens ziemlich überfrachtet.

> Die Frage ist doch viel mehr, wie sinnvoll die Features sind, oder nicht?
> Weiters können viele "Features" doch gar nicht "nervig" sein (z.B. das
> Überladen von Operatoren).
> Daher stellt sich schlussendlich die Frage, welche Features "nervig" UND
> "sinnlos" sind. Kannst du mir da ein paar aufzählen?

Das Überladen von Operatoren kann sicher ein nützliches Feature sein - wenn es nicht übertrieben wird und es dabei keine Überraschungen gibt.

Möchte nicht zu viel dazu schreiben und verweise einfach mal auf [4].

> > - Für die meisten Anwendungen zu sehr auf Performance ausgerichtet,
> > Einfachheit und Speichersicherheit erst an zweiter Stelle
> Es gibt zwar keine herkömmliche Garbage Collection, dafür aber GC je
> Pointer / auf Objektbasis
> -> Smart Pointer: in C++ std::auto_ptr und in C++11 zusätzlich
> std::unique_ptr, std::shared_ptr und std::weak_ptr
> afaik entspricht ein unique_ptr einem auto_ptr, womit dieser obsolete wird
> Dieses GC-System (von C++) ist zwar nicht ganz so einfach wie ein
> herkömmliches, dafür ist es aber weit flexibler und effizienter. Es wird
> genauso wie in Goo keine Laufzeitumgebung benötigt und ist daher relativ
> effizient, wobei C++ wohl noch ein bisschen effizienter sein dürfte als
> Goo. Zusätzlich kann bei kritischen Stellen (hohe Performance benötigt) die
> Speicherverwaltung selbst übernommen werden, womit in C++ keine
> Notwendigkeit besteht, für Performance-kritische Anwendungen Bindings zu
> verwenden, wie sonst üblich.
> Wie sieht es aber außerhalb der GC aus? - in welchen Bereichen ist Goo
> wirklich einfacher?
> einer fällt mir selbst ein: Aufbau eines string aus nicht-string Typen
> Aber sonst?

Go beschränkt sich auf das Nötigste, bietet aber auch einigen Komfort. U.a. durch angenehme Syntax für eingebaute Typen. Beim Software-Design entfällt z.B. das unsägliche, OOP-Sprachen vorbehaltene, Austüfteln der idealen Klassenhierarchie. Das Parade-Feature von Go ist aber die Unterstützung von Concurrency.

> > - Build dauert sehr lang weil C++ kein Modulsystem hat
> Klassen und Funktionen können in Namespaces verpackt werden, was dann so
> eine Art Modul ist.

Das bringt zwar etwas Struktur in die Sache, aber es hat keinen Einfluß auf die langsame Kompilierung. Für C++ wurde ein Modulsystem vorgeschlagen [5], aber soweit mir bekannt ist noch nicht in C++11 implementiert.

> Du sprichst etwas an, das ich gerne wüsste:
> Wie schafft es Goo eigentlich, so eine niedrige Kompilierzeit zu
> erreichen?

Siehe [6].

> > - Kryptische Fehlermeldungen von Compiler und Linker
> Das stimmt wohl, ist aber auch teilweise Compilerabhängig.
> Es ist aber wohl auch nur Gewohnheitssache und die SA (Syntax Analysis)
> einer IDE kann einem dabei das Leben auch stark vereinfachen.
>
> > - Kleine und mäßig hilfreiche Standardlibrary
> Das stimmt wohl auch, wird auch durch C++11 etwas verbessert, aber wie
> sieht es da bei Goo aus?
> Also GUI-Support gibt es ja nicht, sonst hättet ihr ja die vorhandene
> Funktionalität genommen, oder?
> Wie sieht es mit Netzwerk, Multimedia und Kommunikation aus?

Siehe [7].

> > - Schlechte Unterstützung für Concurrency
> In normalem C++ afaik gar keine Unterstützung, mit C++11 kommt jedoch
> vollständige Unterstützung hinzu.
>
> Das könnte dann z.B. so aussehen:
> #include
> #include
> #include
> #include
> using namespace std;
>
> mutex m;
> void func(int n) {
> lock_guard lk(m);
> cout << "Launched by thread " << n << endl;
> }
>
> int main() {
> int n = 10; // number of threads
>
> //Launch a group of threads
> vector th;
> for (int i = 0; i < n; ++i)
> th.push_back(thread(func, i));
>
> //Join the threads with the main thread
> for (auto &t : th)
> t.join();
>
> return 0;
> }
> (heute funktionsfähiger Code mit einem Standard-Compiler)

Zehn Threads sind sicher kein Problem, aber wie sieht es mit 100000 aus? Das Hantieren mit Low-Level Locking-Mechanismen wie Mutexes würde ich auch nicht gerade als besonders angenehm bezeichnen.

Concurrency dient zur Strukturierung von Software, nicht zur optimalen Ausnutzung mehrerer CPUs oder Kerne, was wiederum Thema der Parallelisierung ist.

> > - Keine Stacktraces bei Crashes
> Auch ein Punkt, der stimmt, aber durch eine IDE mit Debugger, denke ich,
> nicht so schlimm ist.

Es sei denn der Crash tritt beim Kunden auf, wenn es um lokal installierte Software geht.

> > > > Mit Go bekommst Du dann halt auch noch (fast) alles aus
> > > > einer Hand: Compiler, Build- und Paket-Tool, saubere Doku,
> umfassende
> > > aber
> > > > nicht überfrachtete Standardlibrary.
> > > Und wieso nimmt man nicht einfach ne IDE?
> >
> > Viele Entwickler möchten oder können aus verschiedensten Gründen nicht
> mit
> > einer IDE arbeiten.
> Die da wären?

Hier nur einige:
- Nicht immer für alle wichtigen Plattformen verfügbar
- Bloat (VS, Eclipse, ...)
- Unterstützen oft nicht alle Features der Toolchain

Ich will auch gar nicht gegen IDEs feuern, weil ich diese selbst gern nutze. Eine IDE kann aber, egal wie gut sie ist, aus einer Sprache mit zu vielen Altlasten keine moderne, schlanke und einfache Sprache machen.

> Bei Skriptsprachen verstehe ich das ja noch, aber wenn der Quelltext ja
> sowieso kompiliert werden muss ...
> Außerdem ist mit einer IDE Rafactoring, Projektverwaltung und Kollaboration
> doch viel einfacher, nicht?

Refactoring ist tatsächlich eine wunderbare Sache, wenn es robust funktioniert. Kollaboration kann auch erschwert werden, etwa bei Crossplattform-Projekten, wenn die IDE nicht für alle Plattformen erhältlich ist.

> > Eine IDE kann auch nicht alle schlechten Merkmale einer
> > Programmiersprache und ihres Ökosystems kaschieren.
> Klar.
>
> > > > und, als c++ programmierer ganz wichtig: gibt es in go einen echten
> > > string
> > > > datentyp? :-)
> > > Wieso ist der in C++ nicht echt?
> >
> > Es ist halt "nur" ein x-beliebiger Library-Typ ohne direkte
> > Sprachunterstützung. Schau Dich mal um, viele Projekte ziehen es vor
> einen
> > eigenen String-Typ zu verwenden. Warum ist das so, wenn std::string doch
> so
> > toll ist?
> Wie ich schon (oben) erwähnt habe, ist std::string sicher nicht perfekt,
> aber wie kann denn ein eigener string-Typ besser sein?
> Tut mir leid, ich bin noch nicht so ein erfahrener C++-Entwickler und kenne
> auch keine Projekte, die einen eigenen String-Typ verwenden.
> Bis auf (den bereits erwähnten) Aufbau eines strings und das Parsen zu
> anderen Datentypen, das beides vll. nicht so intuitiv sind, fällt mir jetzt
> nichts spontan ein.

Beispiele für bekannte C++ Projekte mit eigenem String-Typ:
Qt, WxWidgets, Ogre 3D Engine

Hauptgrund für einen eigenen String-Typ in diesen Projekten ist vermutlich der Wunsch nach einem möglichst angenehmen und konsistenten API. Auch Unterstützung für bestimmte Kodierungen oder Performance dürften eine wichtige Rolle spielen.

[1] http://godashboard.appspot.com/
[2] http://go-lang.cat-v.org/library-bindings
[3] https://github.com/skelterjohn/go.uik
[4] http://harmful.cat-v.org/software/
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf
[6] http://stackoverflow.com/questions/2976630/why-does-go-compile-quickly
[7] http://golang.org/pkg/