Foto: eumates | shutterstock.com
Im Jahr 2007 wurden einige Softwareentwickler bei Google mit zunehmenden Problemen konfrontiert: Sie mussten Millionen von Codezeilen managen, die fortlaufend Daten für das World Wide Web lieferten und die Aufgabe hatten, weltweit Millionen von Netzwerkverbindungen zu händeln. Eine enorme Herausforderung, bei der die damals etablierten Programmiersprachen keine große Hilfe waren. Im Gegenteil: Ihre zahlreichen Eigenheiten und ihr Fehlerpotenzial waren eher kontraproduktiv. Weil es keine Alternative gab, um die I/O-Aufgaben mit möglichst wenig Code, aber unter optimalen Security-Rahmenbedingungen abzuarbeiten, entschieden sich die Entwickler dafür, "einfach" selbst eine Sprache auf die Beine zu stellen - die Geburtsstunde von Go (auch Golang).
Bis heute investiert der Google-Konzern weiter in Golang - was auch daran liegt, dass weite Teile der Infrastruktur des Suchmaschinenriesen auf dieser Grundlage laufen. Darüber hinaus haben sich aber auch viele andere Programmierer der Open-Source-Sprache verschrieben - wie auch ihre Platzierung in der Top 10 des Tiobe-Index zeigt. Dazu haben die Simplizität von Go sowie die Ähnlichkeiten zu C und Java ohne Zweifel beigetragen. Allerdings gehört auch zur Wahrheit, dass diese (und weitere) Features von Go unter Entwicklern nicht unumstritten sind: Was die einen feiern, ist für die anderen eher kein Grund zur Extase. Im Folgenden haben wir sieben Gründe zusammengetragen, warum Go von Softwareentwicklern gleichermaßen gehasst und geliebt wird.
Fun gopher animation on the gopher badge using @TinyGolang #golang #gophercon pic.twitter.com/06OHJP8YlE
— Justin Zemlyansky (@Th3_t1nk3r3r) July 8, 2024
1. Die Lernkurve
Die Entwickler von Go wollten mit voller Absicht eine Programmierspache schaffen, die schnell zu erlernen ist. Deswegen haben sie bei der Entwicklung auch auf übermäßig komplexe Funktionalitäten oder Eigenheiten verzichtet. Stattdessen haben sie sich darauf fokussiert, Go auf das Wesentliche zu reduzieren.
Die Gründe, das zu lieben: Unerfahrene Entwickler tun sich beim Einstieg mit Golang deutlich leichter. Weniger Funktionen und Syntax-Konstrukte sorgen für eine flache Lernkurve und einfach zu lesenden Programmcode. Das hat auch für erfahrene Devs Vorteile: Sie können Go innerhalb eines Tages erlernen.
Die Gründe, das zu hassen: Simpel ist nicht gleich minderwertig - dennoch beschleicht nicht wenige Programmierer aufgrund der asketischen Funktionen bei der Arbeit mit Go das Gefühl, nicht ihr volles Potenzial entfalten zu können.
2. Die C-basierte Syntax
Die Schöpfer von Go sind tief in der Unix-Welt verwurzelt. Und das merkt man auch: Die Syntax dürfte direkt jedem Dev vertraut vorkommen, der schon einmal mit Programmiersprachen gearbeitet hat, die von C abgeleitet sind - etwa Java oder C#. Zwar haben die Verantwortlichen im Vergleich zu traditionellem C einige Details angepasst, um Go einen moderneren Look zu verleihen - dennoch sind die Ursprünge unübersehbar.
Die Gründe, das zu lieben: Alle Devs, die mit dem C-Stil "groß geworden" sind, dürfte der Umgang mit Golang und seiner Syntax intuitiv von der Hand gehen.
Die Gründe, das zu hassen: Jeder Entwickler, der den Ansatz von Python vorzieht, wird an Golang diverse Dinge auszusetzen haben: Es gibt keine Möglichkeit, Codeblöcke abzugrenzen und die Typisierung ist bewusst dynamisch gehalten. Aus dieser Perspektive fühlt sich Programmieren wie Go eher wie ein Rückschritt an.
3. Das Regelwerk
Die Macher von Go wollten jedoch nicht nur die Syntax, sondern auch den Stil und die Usage Patterns der Programmiersprache definieren. Deshalb entschieden sie sich (zum Beispiel) dafür, eine Standard-Bibliothek für Formatierungen zu entwickeln. Zudem verbannten sie auch einige verpönte Eigenschaften anderer Sprachen, etwa ungenutzte Variablen oder zyklische Abhängigkeiten. Wann immer diese Elemente in der Go-Codebasis auftauchen, kommt der Build-Prozess programmatisch bedingt zum Erliegen.
Die Gründe, das zu lieben: Die stark idiomatischen Regeln von Go sorgen dafür, dass der Code leichter zu verstehen ist. Das eliminiert potenzielle Konfliktherde, weil es weniger Optionen und gute Gründe dafür gibt, seinen eigenen Programmierstil einzubringen.
Die Gründe, das zu hassen: All die zusätzlichen Regeln und Konventionen können sich für manche Entwickler wie ein Korsett anfühlen, das ihnen die Freiheit raubt.
4. Die Error-Handling-Extrawurst
Ein wesentlicher Teil der modernen Entwicklungsarbeit besteht darin, zusätzliche Code-Pfade zu schaffen falls Fehler auftreten. Diesbezüglich verfolgt Go einen anderen Ansatz: Es ermöglicht Entwicklern, beide Pfade in dieselbe Funktion zu schreiben - also mit ihrem Code sowohl das normale Prozedere, als auch das im Fall eines Fehlers zu beschreiben. Es existiert deshalb auch ein eigenes Type-System für Fehler, das es Devs erlaubt, spezifische Fehlertypen zu erstellen und anschließend festzulegen, wie diese behandelt werden sollen.
Die Gründe, das zu lieben: Der Golang-Ansatz erkennt die Existenz von Fehlern an und ermutigt Programmierer, einen Plan dafür zu machen, wenn diese behandelt werden müssen. Das wiederum kann im Ergebnis zu widerstandsfähigerer und damit qualitativ hochwertigerer Software führen.
Die Gründe, das zu hassen: Unnötiges Error Handling kann Go-Funktionen schwerfälliger und komplexer gestalten. Oft muss jede Funktion in einer Deep Chain ähnlichen Code enthalten, der mehr oder weniger das Gleiche mit dem gleichen Fehler macht. Andere Sprachen wie Java oder Python sehen vor, Fehler in einem spezifischen Block zu sammeln, der diese "abfängt". Das kann saubererem Code zuträglich sein.
5. Die Standardbibliothek
Nicht nur die Syntax von Golang ist darauf konzipiert, einen einfachen, aber leistungsfähigen Standard zu liefern, der Entwicklungsteams zusammenführt. Die Standardbibliothek der Programmiersprache bietet Support für die meisten wichtigsten Tasks, die im Bereich webbasierter Microservices relevant werden. Die Input- und Output-Routinen händeln auf niedriger Ebene Netzwerkpakete und bewältigen zudem auch komplexere Aufgaben, etwa wenn es um HTTPS-Protokolle oder JSON-Daten geht, die dekodiert werden müssen. Um einen vollständigen Webserver einzurichten, sind nur wenige Codezeilen erforderlich - weil alles im "net/http"-Part der Bibliothek enthalten ist.
Die Gründe, das zu lieben: Wenn die meisten Standardfunktionen von der Default-Bibliothek übernommen werden, sorgt das für einfacher zu lesenden Code, weil keine eigenen Versionen geschrieben werden oder Diskussionen über Packages und Drittanbieter-Bibliotheken entstehen.
Die Gründe, das zu hassen: Es gibt Entwickler, die den Wettbewerb unter Entwicklern als Indikator für Innovation betrachten. Für sie stellen mehrere Packages, die denselben Task unterstützen, ein Feature einer reichhaltigen Kultur dar.
6. Das Executable
Eine weitere Zielsetzung des Go-Teams bestand darin, es möglichst unkompliziert zu gestalten, Go-Programme bereitzustellen. Das realisierten die Verantwortlichen, indem sie sämtliche Komponenten in einer Executable bündelten: Sämtliche Bibliotheksroutinen von Go sind im Standard-Build inkludiert.
Die Gründe, das zu lieben: Speicherplatz ist billig und Code auszuführen kann zum Albtraum geraten, wenn verschiedene Versionen von Bibliotheken installiert sind. Insofern kann eine Executable viel Zeit sparen.
Die Gründe, das zu hassen: Mit der Zahl der Go-Pogramme steigt auch die Zahl der Kopien der Bibliotheken. Ab einem gewissen Punkt darf man dann auch an der Effizienz zweifeln: Speicherplatz ist zwar günstig, aber Memory-Bandbreite und Caching die wichtigsten Faktoren in Sachen Ausführungsgeschwindigkeit.
7. Der Einfluss von Google
Wie eingangs bereits erwähnt, ist Google nach wie vor der maßgebliche Kontributor für Go - und liefert beispielsweise auch den Compiler und das Gros der Toolchain. Darüber hinaus gibt es zwar weitere Projekte, die Support für Go bieten. Beispielsweise der Transpiler GopherJS, der Go in JavaScript umwandelt. Der wesentliche Teil der Go-Entwicklungsarbeit wird aber von Google geleistet.
Die Gründe, das zu lieben: Ein großer Teil der Dev-Arbeit besteht heute darin, Code für Server-Client-Konstellationen zu schreiben, die auch bei Google einen ganz wesentlichen Teil der Workloads ausmachen. Und was für einen Konzern wie Alphabet gut funktioniert, sollte auch für alle anderen, die mit denselben Herausforderungen kämpfen, eine gute Lösung darstellen.
Die Gründe, das zu hassen: Zentralisierte Autoritätsinstanzen sind unter Entwicklern nicht unbedingt beliebt. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.