My Universe Logo

Go: First Contact

Posted by Jesco Freund at May 8, 2010 12:38 a.m.

Und wieder ist die Welt um eine Programmiersprache reicher geworden – die Rede ist von Go, einer unter Schirmherrschaft von Google entwickelten Sprache, zu deren Vätern auch Vertreter der Unix-Prominenz (wie etwa Ken Thompson) gehören. Auch wenn einige „Fach“-Journalisten (mal wieder) die Sensation wittern und bereits die Totenglocken für C, C++ und Java läuten hören, habe ich mal (entgegen meiner Gewohnheit, bei journaille-generierten Hypes aktiv wegzusehen) ein bisschen mit Go herumgespielt, um mir ein eigenes Urteil erlauben zu können.

Auf den ersten Blick wirkt die Sprache ein bisschen wie „OK, wir nehmen C, fügen Objektorientierung hinzu, ohne die Komplexität von C++ ertragen zu müssen, und packen noch ein bisschen Nebenläufigkeit dazu“. Auf den zweiten Blick offenbart sich, dass die Sprache offenbar einer Hippie-Kommune entsprungen ist – jedenfalls lässt sich nicht mehr so genau sagen, wer die eigentlichen Eltern sind ;-). C und C++ haben auf jeden Fall Pate gestanden (bei Ken & Co. auch nicht anders zu erwarten), aber auch Elemente von Java, Python und sogar Pascal sind mit eingeflossen.

Was mich gleich bei den ersten Versuchen geärgert hat: Die Entwickler konnten sich offenbar nicht entscheiden, die Code-Formatierung entweder strikt vorzugeben (wie etwa bei Python) oder völlig dem Programmierer zu überlassen (wie etwa bei C). So dürfen beispielsweise öffnende Blockklammern nicht alleine in einer Zeile stehen, sondern müssen mit dem öffnenden Element (Funktionsdefinition, Schleifenkopf, etc.) in einer Zeile notiert werden. Bei längeren Funktionsdefinitionen verschlechtert das die Lesbarkeit unnötig; man ist bei größeren Go-Sourcedateien daher auf einen Editor angewiesen, der dem Entwickler mit Syntax Highlighting und Code Folding unter die Arme greift.

Ebenfalls als etwas hinderlich für den Einstieg ist der Umstand, dass es für die Werkzeuge der Go-Toolchain keine Manpages gibt und selbige auch nur mit äußerst spartanischen Hilfetexten ausgestattet sind (die übrigens nur erscheinen, wenn man die Werkzeuge ohne weitere Argumente aufruft). Überhaupt scheinen die Werkzeuge noch etwas unausgereift zu sein. Compiler und Linker müssen separat aufgerufen werden und heißen je nach Architektur anders (z. B. heißt der Compiler auf amd64-Systemen 6g, auf x86 hingegen 8g). Dynamisches linken beherrschen die Basis-Werkzeuge (namentlich der von Plan9 geklaute und modifizierte Linker) ebenfalls nicht; hierfür wird eine modifizierte GCC-Version namens gccgo benötigt.

A propos linken: Ich habe mir mal den Spaß gemacht, die Größe eines (statisch gelinkten) Go-Binaries mit einem statisch gelinkten C-Binary zu vergleichen. Als Ausgangsbasis habe ich ein einfaches „Hello World“ Programm verwendet. In Go sieht es folgendermaßen aus:

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!\n")
}

Das C-Pendant sieht entsprechend so aus:

#include <stdio.h>

int main() {
    printf("Hello, World!\n");
    return 0;
}

Die Größe der fertigen Binaries nimmt sich wie folgt aus:

i386_hello.glibc-dynamic              4,4K
i386_hello.glibc-static             566,0K
i386_hello.go-linux                 595,0K

amd64_hello.freebsd-libc-static     263,0K
amd64_hello.go-freebsd              722,0K

Ich hätte nicht erwartet, dass ein gegen die glibc (Version 2.11.1) statisch gelinktes Binary an Größe noch übertroffen würde – Go schafft das jedoch, sogar mit deutlichem Vorsprung 8-). Die großen Binaries sorgen auch dafür, dass in Go geschriebene Programme recht lahm aus den Startlöchern kommen – im Zweifel muss einfach mehr von der Platte gelesen werden als bei einem dynamisch gegen die libc gelinkten Binary.

Alles in allem hält sich meine Begeisterung für Go derzeit noch stark in Grenzen. Die Toolchain ist nicht gerade ein Ausbund an Reife (ok, bei dem Projektalter nicht anders zu erwarten); für den Produktiveinsatz oder die Entwicklung größerer Projekte fehlen einfach noch vernünftige Werkzeuge. Die Sprache selbst ist auch nicht gerade revolutionär und wirkt in einigen Details wie ein fauler Kompromiss – die meisten Dinge, die Go kann, kann irgendeine andere Sprache auch schon, und meist deutlich besser als Go (z. B. Code-Struktur in Python, Objektorientierung in Smalltalk, Nebenläufigkeit in Limbo, …). Im FreeBSD-Forum bin ich auf ein Zitat gestoßen, das wie die Faust auf's Auge passt:

From what I've seen so far, Go looks as ugly as Lisp, Perl, and C++ having a threesome in the back yard. However, I find it strangely appealing,

Was Go interessant macht, ist der Ansatz, eine Synthese aus diesen Dingen zu schaffen, um objektorientiert und nebenläufig programmieren zu können, ohne sich zu sehr von bekannten Code-Layouts und Syntax-Konstrukten entfernen zu müssen. Mir drängt sich jedenfalls die Frage auf, ob Google der Welt mit einem vom Big Interpreter Lock befreiten und auf Performance getrimmten Python-Interpreter nebst eines verbesserten Threading-Interface nicht den größeren Gefallen getan hätte…

2 comments | Defined tags for this entry: C, Go, google, programming, python

Comments

An einem ordentlichem Python-Interpreter sitzt Google ja auch dran: http://code.google.com/p/unladen-swallow/

Aber manchmal geht mir dynamic-typing einfach auf den keks.

Gruß
FreeBSD nerd

wurstgott on May 8, 2010 01:53 CEST

Nice, Unladen Swallow kannte ich bis dato nicht. Allerdings verraten deren Dokumente, dass es alles andere als trivial ist, dem GIL den Garaus zu machen - Implementierungsversuche mit einem Garbage Collector anstelle des klassischen RefCountings in CPython waren jedenfalls nicht sehr erfolgreich; zumindest nicht im Hinblick auf die Performance. Den Ansatz, per JIT gleich Maschinencode zu erzeugen, finde ich hingegen sehr charmant. Werd's mal im Auge behalten; so lange baue ich performance-kritisches Zeugs halt weiter in C :-)

Jesco on May 9, 2010 17:51 CEST