Go (Golang) 2 - wann es kommt, was es kann // deutsch

[@MegaHarko]

wtb: enums ob in v2 oder v1.x ist mir dabei egal....

[@yahmk3978]

Vielen Dank für diesen Betrag.

[@hichaeretaqua]

Grundsätzlich verstehe ich das Argument, das C# durch seine vielen Neurungen unübersichtlich geworden ist. Allerdings kann ich mich noch erinnern wie leicht ich C# empfand als ich von Java kam. Ich musste viel weniger schreiben um das gleiche Auszudrücken (properties, delegates, extension methods). Diese Leichtigkeit wurde erkauft mit neuen Sprachkonstrukten. Ich fand das damals super. Auch heute gibt es immernoch Features, bei denen ich froh bin das Sie Teil der Sprache geworden sind. Wenn ich nur daran denke was früher an Code notwendig war um ein einfaches unveränderliches DTO zu schreiben, dann wird mit schlecht. Heute ist das ein Einzeiler. Aber ich habe auch mit Anfängern zu tun, für die es eine riese Herausforderung ist C# zu lernen. Wie würde eine Kompromiss aussehen? So wie vor 10 Jahren möchte ich C# heute nicht schreiben. Breaking chances, wo bestimmte Sprachkonzpte beerdigt werden, wäre ein Option. Aber jeder mit einer großen Codebasis würde da sicherlich Sturm laufen. Ich betrachten den Weg den C# geht aktuell als das kleinere Übel. Mit Analysern, editorconfig und co lässt sich das Übel im Zaum halten.

[@deado7282]

Eine Sache die GO noch braucht sind Generics bei Methoden oder zumindest noch weitere Standard-Methoden auf Slices

[@IPLAYPOE]

Gibt's doch?

[@deado7282]

@@IPLAYPOE Um mit den Worten des Compilers (1.21.4) zu Antworten: "method must have no type parameter"

[@henninghoefer]

Kleine Korrektur zu 10:15: Go ist 14 Jahre alt, aber Go 1 noch nicht (veröffentlicht 28. März 2012). Daher kann auch das Kompatibilitätsversprechen noch nicht so alt sein.

[@maniheister]

Grade wegen der einfachheit des Codes finde ich GO so faszinierend. Die Abwärtskompatibilität ist einfach nur noch das Sahenhäubchen 🤗

[@nimmneun]

Beschäftige mich erst seit diesem Sommer mit Go aber genieße die herrlich unaufgeregte Sprache, Eco & Community. Vor allem im vgl. zu JS und Co 😂 Go is halt für gechillte Leute ... so mein Eindruck 😌

[@anglartool_de]

Was aber in GO wirklich einmal Wirklichkeit werden sollte, ist eine native GUI. Leider ist das (für mich) ein K(r)ampf. Insbesondere wenn es eine Desktop Anwendung (anstatt C#) auf einem Windows (ja-doch Win10) werden soll. Oder ist da ein Video von the native web GmbH angesagt?

[@he2he]

Ist es wirklich einfacher, wenn ich statt for bei Listen und while bei Bedingungen für beide Schleifenformen for schreibe? Ist eine API möglichst einfach, wenn ich einfach allen Dingen den gleichen Namen gebe und es nur anhand er Parameter differenziere?

[@paninger]

Genau mein Gedanke 👍

[@MegaHarko]

Naja ich find das Beispiel zwar auch immer ein bisschen merkwuerdig, aber was das API-beispiel angeht: Artverwandtes zusammenzufassen macht schon sinn. Man stelle sich ne Software vor die daten abholt und durch unterschiedliche nodes leitet um diese zu modifizieren. Die nodes kann ich dynamisch hinzufuegen. Dafuer hab ich einen AddNode endpunkt, dem man noch den NodeType als parameter uebergibt. Waere es nun besser sein fuer jeden NodeType einen extra Endpunkt zu haben?

[@khmarbaise]

Diese Vorgehen, dass die Rückwärtskompatibilität gehalten wird . macht Java schon etwas länger...

[@thenativeweb]

Ich schätze, Java ist auch so ein Thema, dem ich mal wieder eine Chance geben sollte … zumindest, um mich einfach mal wieder auf den aktuellen Stand zu bringen. J2EE 1.4 ist nun doch schon eine Weile her 🤣

[@toTheMuh]

Bei der Syntax wünsche ich mir eine gewisse Überarbeitung und Vereinheitlichung. Gerade arrays und slices kann man beim überfliegen des Codes schnell verwechseln und es wäre echt cool, wenn man slices auf die selbe Art wie maps erstellen könnte. Also sowas wie s := make(slice[T], len, cap). Auch die Initialisierung von Variablen sollten vereinheitlich werden. Außerhalb einer Funktion geht nur var/const variableNaem = value und in einer for loop geht nur variableName := value und innerhalb einer Funktion geht beides. Das ist unnötig verwirrend.

[@yt7042]

So einen Fehler wie bei Python oder Angular die Abwärts Kompatibilität zu brechen und dann beide Versionen jahrelang parallel zu pflegen wird es wohl sobald nicht mehr geben. Schönen Sonntag Abend!

[@clumsyjester459]

Go hat mit einem ziemlich soliden Fundament angefangen und nimmt sehr langsam neue Sprachfeatures auf. Dann muss man auch nicht so häufig die Abwärtskompatibilität brechen. Und natürlich bin ich auch ein Fan davon, wenn Sprachen das nicht leichtfertig machen. Aber solange es selten genug passiert und es entsprechende Tools gibt, die bei der Migration helfen, halte ich das Brechen der Kompatibilität in Ausnahmefällen nicht für das Ende der Welt. JavaScript ist so ziemlich die einzige Sprache, die die Kompatibilität garnicht brechen darf. Und JS hätte es echt nötig. Aber es geht nicht. Einer Sprache ohne Grund ein solches Constraint zu geben ist ein bisschen unnötig.

[@comedyclub333]

IMHO war der Bruch mit der Abwärtskompatibilität in Python überhaupt kein Fehler. Anforderungen ändern sich, besonders bei allgemeinen Sprachen. Um Altlasten loszuwerden MUSSTE irgendwann ein Bruch kommen. Und so, wie er bei Python gehandhabt wurde, lief es eigentlich ganz gut. Es war also mitnichten ein "Fehler". Ich habe um 2016 rum Python gelernt, also genau mitten in der Übergangszeit mit fast mehr Resourcen zu Python 2 als Python 3. Der Übergang von 2 nach 3 war simpel und einfach, zudem wurde einem genügend Zeit eingeräumt und es gab haufenweise Tools und Packages (z.B. das Migrationstool von CPython, das six-Package oder die imports aus dem virtuellen future-Package), die Übergänge vereinfachen - ganz zu schweigen von der Tatsache, dass man in Python fast ohne Mehraufwand Code schreiben kann, der mit Python 2 und 3 läuft. Rückblickend muss man sagen, dass Breaking Changes in der Praxis oft weniger gravierend sind als ausgemalt - ein gutes Management von Seiten der Sprachentwickler vorrausgesetzt. I.d.R. läuft ja deine Software mit einer fest vorgegebenen Version und man kann in Ruhe im Rahmen des nächsten Refactorings auf die neuste Version umstellen. Es ist ja nicht so, dass deine Software urplötzlich nicht mehr tut. Breaking Changes sind notwendig, um Altlasten loszuwerden. Wenn man von vornherein Abwärtskompatibilität gewährleisten will, führt das zwangsläufig dazu, dass die Sprache wächst, aber veraltete Dinge nicht mehr loswird. Und genau da sehe ich das Problem an Golang: Die Sprache ist toll und alles, aber wenn die Entwickler sich weigern jemals Altlasten loszuwerden, dann wird Go früher oder später eben das, was es versucht zu vermeiden: Überladen, weil historisch gewachsen. Klar kann man jetzt sagen, dass Neuerungen grundsätzlich eher konservativer aufgenommen werden. Das verlangsamt das Problem zwar, eliminiert es aber nicht. Von daher sehe ich es ähnlich wie @clumsyjester459: Gerade Go mit seiner statischen abhängigkeitsfreien Kompilierung und seiner strengen Versionstreue im Projekt hat es gar nicht nötig, auf Abwärtskompatibilität zu pochen. Warum muss denn ein Go 1-Programm mit einem hypothetischen Go 2 kompilierbar sein? Das wäre gar kein Problem. Wer das Go 1-Programm dann noch kompilieren will, nimmt einfach die entsprechende Go-Distribution zur Hand.

[@veitkunz7058]

Wenn du behauptest, dass in JavaScript for, for-of und for-in drei verschiedene Schleifen seien, dann musst du aber auch in Go die Varianten trennen: for und for-range wären dann genauso verschiedene Schleifen.

[@dominik4496]

Für Go fehlt mir noch eine gute, freie Lösung PDF Dateien in Text idealerweise mit OCR zu konvertieren. Bisher muss ich dafür immer Apache Tika (Java) bemühen. Ansonsten bin ich als hauptsächlichler PHP, Python Dev sehr happy mit Go.

[@mettbrotchen4367]

pdf2image - seines Zeichens ein Python-Modul, konvertiert PDF-Dateien in Bilder. pytesseract - ebenfalls ein Python-Modul - extrahiert Text aus Bildern mit OCR in Text. Problem gelöst, Herr Python Dev. 😛

[@Hofer2304]

Wie verständlich ist Go für einen Laien, der gerade einen Crashkurs zum Lesen von Go-Programmen gemacht hat?

[@MegaHarko]

Dank der recht einfachen Sprachkonstrukte ist zumindest nicht die Sprache an sich das Hindernis fuer ein Verstaendnis. Verstaendniss dessen was da fachlich abgebildet wird ist weit ausschlaggebender. Und Codequalitaet natuerlich. Auch in Go kann man unschoene Sachen machen die der Uebersichtlichkeit nicht gerade zutraeglich sind.

[@tobiasnickel3750]

ich glaube in ein paar Jahren werden die Go entwickler auch wieder sehen, das die eingefuehrten Generics, keine richtigen Generics wie in java, c# und Typescript sind.

[@veitkunz7058]

Die private, public, protected und so weiter Dinge in C# als Beispiel zu nehmen ist nicht sonderlich sinnvoll, weil es in Go ganz einfach keine Klassen gibt. Deine Videos sind ja eigentlich immer sehr gut, aber heute bist du schon ziemlich auf die Fan-Boy-Rosarote-Brille-Schiene abgerutscht ;)

[@suikast420]

In Java funktioniert das eigentlich auch sehr gut. Das Update auf Java 9 ist die einzige Ausnahme bisher. Da waren einige Anpassungen an deployement zu machen wegen der eingeführen jigsaw. .Net dagegen ist Katastrophe. Da will man keinen update machen😂

[@he2he]

Mit dem Wechsel von Framework auf Core gab es einige Schwierigkeiten, aber von 5 auf 6, auf 7 und jetzt 8 lief bei uns eigentlich problemlos.

[@khmarbaise]

Ich habe schon sehr viel upgrades gemacht... JDK9 ja einige Libs hatten probleme... in der Zwischenzeit JDK9,10,... JDK 21 usw. kein Problem bisher...Laufzeit immer...Code Anpassungen waren auch keine Notwendig... aber manchmal helfen die "neuen" Sprach Features Code einfacher lesbar zu machen..

[@suikast420]

@@khmarbaise so ist es. Jigsaw hat das getan was es verporchen hat 😀

[@tobiasnickel3750]

das mit den For Schleifen das ist auch immer so ein Trugschluss. "nur eine" aber in JS sind so viele. also in go hat man auch dieses eingebaute iterieren ueber interatoren, listen, ranges,... und dann legen die leute auch noch funktionsaufrufe in den Schleifenkopf,... Ich will nicht sagen das JS besser ist, aber go ist es meiner Meinung nach auch nicht.

[@ragnar-the-giant]

Hallo Golo, ich bin ein großer Fan von sowohl C# als auch Go. Deiner Aussage mit mehr Schlüsselwörter täten einer Sprache womöglich eher nicht gut bzw. verschlechtern die Übersichtlichkeit, kann ich gut nachvollziehen und ich sehe auch durchaus den Grund hinter deiner Aussage. Allerdings muss ich wirklich zugeben, dass mir Go an vielen Stellen einfach zu strikt und minimalistisch ist. Die Freiheiten sind da doch durchaus etwas beschränkt. Das fängt schon mit so merkwürdigen Entscheidungen wie privaten Funktionen an. Die genannten Schlüsselwörter aus C# könnte ich dir natürlich alle auf Anhieb erklären. Ich finde internal, protected und private auch alle durchweg sinnvoll und verwende diese immer wieder. Ich würde jedes einzelne vermissen, würde MS eines entfernen. Der Aussage, dass C# jetzt schlechter durchdacht sei als Go würde ich auch nicht direkt folgen. Warten wir einfach mal ab, wie sich Go weiter entwickelt. Fantastisch sind jedenfalls beide Sprachen und ich arbeite wirklich sehr gerne damit. Dotnet bleibt allerdings weiterhin meine große Liebe. Hier ist Go jedoch die einzige Sprache, die für mich als Ersatz in Betracht käme.

[@tobiasnickel3750]

macht auch sinn, Go 2 wuerde nur ne community splitten. und wenn sie wirklich ne Idee fuer eine bessere Sprache haben, und dort einbauen was mit Go gelernt wurde. (auch Java lernt von den Go Routinen) und dann koennen sie es vielleicht FLY nennen. so koennen go programme immer gut weiter gehen, updaten und Wenn die entwickler, Projekte und Firmen Bock haben auf die neue Sprache, dann koennen sie in der eigenen Geschwindigkeit Migrieren oder auch nicht.

[@khmarbaise]

In Java nennt sich das VirtualThreads ... schon länger angekündigt und nun in JDK21 drin... schlicht kompatibel wie bisher...

[@mettbrotchen4367]

Was mich persönlich am Konzept von Go sehr stört, ist die Tatsache, dass kein Dynamic Linking gibt ... jedes Binary schleppt alle verwendeten Dependencies direkt mit. Eine lächerliche "Hallo Welt"-Ausgabe auf dem Bildschirm hat als kompiliertes Programm mal so eben 2 MB. Jetzt mag man argumentieren, dass das bei heutigen Speicherplatzdimensionen keine Rolle mehr spiele, aber ich möchte auch nicht zig mal die net/http - Library auf dem Rechner haben, nur weil ich mehrere Go-Programme habe, die das benötigen. Solange alles statisch gelinkt wird, wird Go für mich keine ernstzunehmende Sprache sein - Sprachkomplexität hin oder her. Dann wusel ich lieber mit while, for, foreach, do while, private, public, protected etc. herum und habe trotzdem mehr Freude am Computerleben.

[@MegaHarko]

Interessante Sicht auf die Dinge. Ich fuer meinen teil finde das gut so wie es ist. Dependency Hell ist damit vergangenheit. Dafuer opfere ich mehr als gerne ein bisserl mehr Speicher. So hat jeder seine eigenen Prioritaeten :)

[@markusesslinger]

Na was ist denn die große Alternative? Docker, wo man gleich ein ganzes Betriebssystem mit verpackt, damit man sicher sein kann, dass das eigentliche Programm lauffähig ist. Da ist Go schon besser aufgestellt.

[@jimbone6460]

Go 2.0 wird nicht kommen, haben Rob Pike etc. schon bestätigt aufgrund der Abwärtskompatibilität die Go bietet und das wäre mit Go 2.0 wohl nicht gegeben