Die Lügen, die wir uns erzählen, um weiter Golang zu nutzen (2022)

• Der Autor ist ein Schnabeltier

  • Den Autor als unfähig abzutun, um die Kritik zu ignorieren, ist ein fauler Ansatz.
  • Junior-Entwickler können Probleme mit einem neuen Blick betrachten, und genau das ist ein wichtiger Grund, sie einzustellen.
  • Der Autor ist kein Junior-Entwickler und verfügt durch vielfältige Erfahrungen über ein Verständnis für Sprachdesign.

• Meine Mutter raucht, also wird es schon okay sein

  • Technologien anderer Unternehmen blind zu übernehmen, ist ineffizient.
  • Tech-Blogs dienen auch dazu, das Image eines Unternehmens besser erscheinen zu lassen.
  • Der Blog von Tailscale ist ehrlich, aber es braucht viel Aufwand, um die Probleme von Go zu umgehen.

• Die guten Seiten

  • Go hat eine hervorragende asynchrone Runtime und einen starken Garbage Collector.
  • Werkzeuge für Paketverwaltung, Refactoring und Cross-Compiling sind einfach zu benutzen.
  • Die Nachteile von Go lassen sich jedoch nicht ignorieren, und problematisch ist, dass das Sprachdesign eher zufällig entstanden ist.

• Go ist eine Insel

  • Go hat nur geringe Interoperabilität mit anderen Sprachen.
  • Die Toolchain von Go ist eigenwillig, und vorhandene Assemblersprachen oder Debugger lassen sich nicht verwenden.
  • Die einfachste Methode zur Integration mit Go führt über Netzwerkgrenzen.

• Alles oder nichts (also nichts tun)

  • In Go können Strukturfelder uninitialisiert bleiben.
  • Die Vorstellung, dass Zero Values eine sinnvolle Bedeutung haben, ist naiv und führt in vielen Fällen zu Problemen.
  • Die Kultur rund um Go sagt eher „Pass auf“ statt Probleme tatsächlich zu lösen.

• "Rust ist perfekt und ihr seid alle dumm"

  • Rust kann schrittweise eingeführt werden und integriert sich gut mit anderen Sprachen.
  • Der Erfolg von Rust liegt teilweise darin, dass der Wechsel zu einer sicheren Sprache möglich ist.
  • Auch Rust hat Probleme, aber diese werden schrittweise gelöst.

• Go als Prototyping-/Starter-Sprache verwenden

  • Go gilt als leicht zu erlernende Sprache, tatsächlich braucht man jedoch viel Erfahrung.
  • Es fehlen Funktionen, die klar erkennbar machen, dass Code falsch ist.
  • Die Nachteile von Go treten mit der Zeit zutage, und es ist keine Sprache, von der man sich leicht wieder wegbewegt.

• Die Lügen darüber, warum wir Golang weiter benutzen

  • Wenn andere es benutzen, wird es für uns auch gut sein
  • Sprachdesignfehler einzeln oder insgesamt als akzeptabel anzusehen
  • Zu glauben, man könne die Probleme mit genügend Vorsicht überwinden
  • Zu glauben, dass produktive Softwareentwicklung leicht sei, nur weil das Schreiben leicht ist
  • Zu glauben, dass alles einfach ist, nur weil die Sprache einfach ist
  • Zu glauben, dass man es später jederzeit neu schreiben kann

[tsboard]

Ich weiß nicht, ob ich als Amateur, der sich nur für einen augenblicklich kurzen Zeitraum intensiv mit Go beschäftigt hat, überhaupt etwas dazu schreiben sollte, aber ... Bei Go sind die Vor- und Nachteile wirklich sehr klar, deshalb scheinen sowohl die, die sich dafür entscheiden, als auch die, die es meiden, jeweils gute Gründe zu haben. Persönlich finde ich, dass man es nicht mit Rust vergleichen sollte, sondern eher mit Kotlin (Java).

Die Goroutines von Go sind wirklich hervorragend, aber sie sind keine Magie. Gerade im Backend ist diese Nebenläufigkeit in kleinen Projekten, die nur ein einziges MySQL verwenden, sehr schwer zu beherrschen. Dinge wie die Erschöpfung von MySQL-Ressourcen oder das Management des Pools, um die man sich in JS/TS-Runtimes nicht allzu sehr kümmern muss, sind schwieriger als gedacht. Am Ende wird in dieser Situation die DB zum Flaschenhals, sodass der Vorteil von Gos Nebenläufigkeit teilweise verblasst. (Asynchrones I/O oder der Event Loop von JS/TS-Runtimes könnten sogar passender sein.) Das merkt man sofort, wenn man mit einem Tool wie hey einfach mal -c 100 ausprobiert.

Und obwohl es einen hervorragenden GC gibt, heißt das nicht, dass man leichtfertig nur Pointer auf Objekte weiterreichen und sich dann nicht mehr um das Aufräumen kümmern sollte. Alles ist ein Trade-off, aber auch in Go ist es besser, wenn möglich kleinere Objekte einfach per Wertkopie zu übergeben, damit sie direkt verarbeitet werden, wenn die Funktion endet. Vielleicht hänge ich da in einer veralteten Denkweise fest, aber man sollte Pointer nicht so leicht aus einer Effizienzperspektive betrachten wie in C/C++.

Dass man error beim Rückgabewert von Funktionen fast jedes Mal zurückgeben und dann jedes Mal mit if err != nil {} prüfen muss, ist wirklich lästig, aber das ist auch ein Vorteil. Es ist kostengünstiger als try catch. Und das Schlüsselwort defer, das eine ähnliche Rolle wie finally {} übernimmt, ist ebenfalls großartig. Es ist gut, dass man sich keine Gedanken über den Zeitpunkt der Freigabe von Ressourcen machen muss. Schön ist auch, dass man allein mit der Standardbibliothek sofort einen hervorragenden Backend-Server aufbauen kann (ab 1.23). Vor allem ist es am besten, dass man nach dem Build für das Ziel-OS keine andere Runtime und keine Vorinstallation braucht.

Ich habe Go nicht besonders lange benutzt, aber ich glaube, ich schreibe schon zu lang über eine allzu persönliche Meinung, also höre ich hier auf. Haha, ich mag Go, und ich mag auch andere Sprachen!

[GN⁺]

Hacker-News-Kommentare

• Es gibt viele Kritikpunkte an der Sprache Go, aber die explizite Fehlerbehandlung gehört nicht dazu. Exception-Handling fügt eine Art „magische“ Schicht hinzu, in der man zu leicht Fehler machen kann. Für persönliche Projekte bevorzuge ich Rust, aber in großen Projekten mit Entwicklern auf sehr unterschiedlichem Niveau ist Gos Philosophie der vernünftigste Ansatz zur Fehlerbehandlung in der modernen Welt.

  • Go wird wegen seiner Einfachheit stärker angenommen als andere „neue“ Sprachen. Es ist nicht die beste Sprache, aber wegen vieler eingebauter Vorgaben oft die beste Wahl als Allzwecksprache.

• Rust und Go sind sehr unterschiedlich, und die Mitte, die sich die Leute wünschen, existiert derzeit nicht.

  • Es braucht eine relativ einfache Sprache mit einem Typsystem ähnlich dem von Rust.
  • Gleam und Kotlin sind ein bisschen ähnlich, aber nicht ganz. Rust ist zu komplex und daher für Nicht-Informatiker oder Nicht-Spezialisten schwierig.
  • Es gibt keine perfekte Sprache, aber Go und Rust haben Erstaunliches hervorgebracht. Hoffentlich entsteht, inspiriert von beiden Sprachen, eine einfache Programmiersprache, die breit nutzbar ist.

• Ich mag einfache Sprachen. Da Technik immer mit Trade-offs verbunden ist, ist ausgewogene Kritik wichtig.

  • Es wird ein Blog-Link geteilt, warum Go gewählt wurde.

• Ich frage mich, warum es so wichtig ist, eine Sprache zu kritisieren. Die Kritik ist nicht in einem konstruktiven Stil geschrieben.

  • Jede Sprache kann kritisiert werden. Go funktioniert in Projekten hervorragend, trotz der Unterschiede zu „anspruchsvolleren“ Sprachen.
  • Man gibt dem Go-Team Feedback, beobachtet die langsame Weiterentwicklung der Sprache und stellt der Community weiterhin Dienste zur Verfügung.

• Jedes Mal, wenn ich Kritik an Go lese, werde ich Go trotzdem weiter verwenden.

  • Theoretisch gibt es viele Probleme, aber in der Praxis ist es immer noch eine gute Programmiersprache.
  • Ich mag die explizite Fehlerbehandlung. An den Nachteilen anderer Sprachen störe ich mich auch nicht besonders.
  • Wer empfindlich auf Gos Schwächen reagiert, wird weiter klagen. Man wählt einfach die Sprache, die am besten zu einem passt.

• Jedes Mal, wenn ich andere Sprachen benutze, möchte ich zu Go zurückkehren.

  • Bei Go installiert man es, lädt den Code herunter und schreibt los. Man muss sich keine Gedanken über Versionen, Runtime, Konfiguration, Build-Tools, Package-Manager und Ähnliches machen.
  • Rust kann ein ähnliches Erlebnis bieten. Wenn ich Python, Typescript oder Java benutze, machen mir die Probleme rund um die Konfiguration das Programmieren unangenehm.

• Ich war auf der Suche nach einem besseren Python. Go war die naheliegende Wahl, aber ich mag die Syntax nicht.

  • Rust verwendet viele Sonderzeichen, und Lisp mag ich wegen der Klammern und der umgekehrten polnischen Notation nicht.
  • Ich kompiliere Python-Code mit Nuitka und liefere ihn als Binärdatei aus. Ich interessiere mich für AOT-Kompilierung in C#.
  • Ich mag Nim und Crystal, aber die kleinen Communities sind eine Hürde. Nim ist trotz seiner kleinen Community eine großartige Sprache.

• Ich weiß nicht, warum Go und Rust so oft verglichen werden. Ein Vergleich mit Java wäre passender.