Seht Ihr Golang auch als rückschrittlich an?

[SimonX]

Ich muss meinen Unmut mal unbedingt loswerden:

Unsere Firma hat sich entschieden hauptsächlich Go für neue Projekte einzusetzen.

Beim Lernen und Programmieren in Go fühle ich mich sowas von in die Plain-C Zeit zurückversetzt. Also Pre-2000.

Ich sehe noch keine Sprach-Feature, die mehr als einfache Macro-Replacement sind.

- Das vielbeschworene "go func ..." ist nichts als ein posix thread start

- Die contexts sind nichts als shared storage und man muss die händisch in die func's durchreichen. (Sowas wie context chain wie in nodejs, Fehlanzeige)

- Die channels sind nichts als message queues (posix oder andere) bzw. pipes.

- Das select ist eigentlich ein poll (vielleicht noch mit signal handling) mit oder ohne wait wo dann die channels alles pipes sind.

- Das defer ist das final in aktuellen Hochsprachen.

- Selbst in func's gibt es keine const variablen damit man ein compile/lint-time Feedback bekommt, wenn man eine var nur einmal setzen und eigentlich nicht mehr ändern wollte.

C habe ich das letzte mal ausgiebig vor 2000 programmiert.
C++ danach.
Ab 2018, python, C#, viel backend typescript mit nodejs und frontend angular
Und nun, 2024, der Rückschritt auf golang.

Ich sehe kein golang Feature, das ein echtes Alleinstellungsmerkmal wäre.

Zumindest gibt es jetzt ein richtiges Internet, so das man längliche Go Konstrukte für verschiedene Probleme finden kann. Aber hier sollte man heutzutage auf jeden Fall auch noch nach fertige OpenSource Packages suchen, anstelle Code zu duplizieren. (Das ist ja der Programmierstyle für typescript und C#. Suche die Lösung in den Opensource Packages und füge einen Control-Flow hinzu)

Ich vermisse all die Annehmlichkeiten von aktuellen Highlevelsprachen, die allein schon das Tippen reduzieren.

Allein schon das "if err != nil { return ... }" überall oder das "err == nil" anstelle von einem kurzen "!err" bzw. "if err { return ... }" bläht den Code ohne Mehrwert auf

Ein lodash Replacement für Go habe ich jetzt auch gefunden und nutze es wo immer möglich.

BTW: C ist nicht viel mehr als Macro-Assembler+Linter und auf dem Level sehe ich Go.

PS:
Beim Suchen nach Möglichkeiten zum Reduzieren von Code Duplicates habe ich eben gefunden:
https://programmingpercy.tech/blog/goto-hell-with-labels-in-golang/

Besonders:
The second example of usage is found in go/types ....
but they also use goto to standardize the error handling and avoid duplicating code.

Wir sind wohl doch eher back to the 1980 mit C64 Basic.

[Shink]

Unsere Firma hat sich entschieden hauptsächlich Go für neue Projekte einzusetzen.
Warum machen die sowas?

[SimonX]

Gute Frage. Es standen Go und Rust zur Auswahl. Es wurde Go gewählt, will es einfacher zu lernen seien soll. Aber schnelle Entwickeln? Glaube ich nicht. Einfach zu viel Tippen.

In der Chef-Etage ist das 2010 Mantra "alles gleich, damit jeder an allem mitarbeiten kann" eingezogen, obwohl doch heute eher "Choose the best (Language, Tool-Chain) for the Job" angesagt ist. Es gibt ja so viel zur Auswahl.

"alles gleich, damit jeder an allem mitarbeiten kann" funktioniert sowieso nicht. Schon wegen dem spezifischem Projekt/Produkt-Context

[nalye]

Kubernetes laeuft auf Go. Kubernetes ist der "neue" Shit. Ergo ist Go das Mittel der Wahl fuer viele Firmen. Das Operatorframework ist aber echt schlimmer als alles andere.

[Exxtreme]

Für mich sieht die Entscheidung eher nach "cargo cult" aus: ist von Google, ist in Kubernets drin und auf Hackernews finden es alle toll, also muss es was Tolles und Modernes sein.

Und ja, ich halte Golang technisch für eine der überflüssigsten Sprachen ever. Man würde es wohl nichteinmal mit dem A*sch anschauen wenn es nicht von Google wäre. Aber gut, Programmiersprachen haben auch eine starke soziale Komponente.

[Ganon]

obwohl doch heute eher "Choose the best (Language, Tool-Chain) for the Job" angesagt ist. Es gibt ja so viel zur Auswahl

Sehe ich aber auch als kritisch. Nicht aufgrund technischer Sachen, sondern einfach wegen vorhandenem Know-How. Bei uns kommen und gehen Mitarbeiter auch immer mal wieder und die hinterlassen halt ihre Projekte bzw. Anteile an den Projekten. Wenn da jeder Mitarbeiter wählt was er meint für ihn richtig ist, müsste jeder Entwickler in der Firma nicht nur ein oder zwei Sprachen und Frameworks können, sondern 5-6.

Da kann man sich als Unternehmen auch schnell in die Arbeitsunfähigkeit katapultieren, wenn man da da nicht irgendwas festlegt.

Man kann diese konkrete Festlegung natürlich kritisieren, aber nachvollziehbar finde ich diese.

[][immy]

Für mich sieht die Entscheidung eher nach "cargo cult" aus: ist von Google, ist in Kubernets drin und auf Hackernews finden es alle toll, also muss es was Tolles und Modernes sein.

Und ja, ich halte Golang technisch für eine der überflüssigsten Sprachen ever. Man würde es wohl nichteinmal mit dem A*sch anschauen wenn es nicht von Google wäre. Aber gut, Programmiersprachen haben auch eine starke soziale Komponente.
This. Aktuell schießen die Sprachen aber auch aus dem Boden und werden durch große Konzerne gehyped. Dabei fehlt es aber häufig an essentiellen Dingen.

[Milchkanne]

Ich hab go mir mal näher angeschaut, als es als 1.0 erschienen ist. Was mich schon total geflasht hat war, dass man die Spec super lesen kann. Fragen wie was funktioniert, konnte man da teils schneller beantworten, als in nem Tutorial.
Der Einstieg war auch schon ziemlich einfach. Bei Rust brauch ich alleine beim lesen von irgendwelchen Lifetimegeschichten ständig länger. Dann gab es direkt eine einfache Tour durch die Sprache... das war schon ansprechend.

Wirklich tief bin ich aber nie eingestiegen. In Rust hab ich dagegen schon was geschrieben, was mir in jeder anderen Sprache vermutlich den Speicher überlaufen hätte (GC-Sprachen) oder Speicherfehler gehabt hätte...

[Sweepi]

Es standen Go und Rust zur Auswahl. Es wurde Go gewählt, will es einfacher zu lernen seien soll. Aber schnelle Entwickeln? Glaube ich nicht. Einfach zu viel Tippen.

Denen hatte einfach niemand gesagt, dass es Zig (https://ziglang.org/) und Cpp2 (https://hsutter.github.io/cppfront/) gibt :D

[universaL]

Hmm, ganz unabhängig von der Sprache und dass syntaktischer Zucker schön ist... Die Menge was zu tippen ist limitiert doch eher selten... Wenn dass der Fall ist, dann kann es wahrscheinlich auch zu 98% ein Generator ;-)

[Marscel]

Die Beschaffungspolitik war vielleicht sonderbar, aber ich sehe da durchaus Marktnischen für Go – und nein, ich nutze das aktuell auch nicht:

* Du willst einfach cross-plattform Binaries ohne weitere Abhängigkeiten erstellen und deployen können: alles static, keine Java-VM, keine Runtime Libs. Kein großes Packaging, keine großen OS-spezifischen Sachen, nur deine headless Arbeitspferdanwendung. Das seh ich wirklich als Pluspunkt der Environment.

* Du willst was potentiell schnelles implementieren, aber ohne Echtzeitconstraints, und ohne dich mit antikem C, oder den harten Lernkurven von C++ oder Rust beschäftigen zu müssen.

* Also ja, der Sprachstandard ist echt klein, aber ich bin mir sicher, dass der erhöhte Bloat in manchen Situationen immer noch handhabarer ist als vielleicht C++20-STL-Voodoo oder Rust-Lifetime-Annotations zusammenzukriegen.

- Das vielbeschworene "go func ..." ist nichts als ein posix thread start

Hast du Erdbeertörtchen erwartet? :confused:

- Die channels sind nichts als message queues (posix oder andere) bzw. pipes.

- Das select ist eigentlich ein poll (vielleicht noch mit signal handling) mit oder ohne wait wo dann die channels alles pipes sind.

- Das defer ist das final in aktuellen Hochsprachen.

Wo ist da das Problem und was wolltest du da stattdessen haben?

[Exxtreme]

* Du willst einfach cross-plattform Binaries ohne weitere Abhängigkeiten erstellen und deployen können: alles static, keine Java-VM, keine Runtime Libs. Kein großes Packaging, keine großen OS-spezifischen Sachen, nur deine headless Arbeitspferdanwendung. Das seh ich wirklich als Pluspunkt der Environment.


Wobei das alles jetzt auch mit Java geht.

[Marscel]

Wobei das alles jetzt auch mit Java geht.

Wie denn? Das letzte Mal, als ich bei GraalVM geguckt habe, wie ich jetzt ein Mac-Binary auf meiner Kiste bauen kann, stand da sowas wie "Nutz auf Github einfach einen Mac-Runner", oder auch: https://github.com/oracle/graal/issues/407

[Exxtreme]

Wie denn? Das letzte Mal, als ich bei GraalVM geguckt habe, wie ich jetzt ein Mac-Binary auf meiner Kiste bauen kann, stand da sowas wie "Nutz auf Github einfach einen Mac-Runner", oder auch: https://github.com/oracle/graal/issues/407

Also laut offizieller Anleitung geht es:
https://www.graalvm.org/latest/reference-manual/native-image/

[Ganon]

Er redet davon z.B. auf Windows eine macOS Binary zu bauen.

[Exxtreme]

Ohhh, sorry. Hab das nicht verstanden. X-D

[Marscel]

Genau, ich hatte mal einen Use-Case vor Jahren, den wüsste ich bis heute nicht auf dieselbe smoothe Art zu ersetzen wie mit Go:

1. Entwickler erweitert das REST-Interface vom Server.
2. OpenAPI-Spec Generator schreibt daraus die neue Spec.
3. OpenAPI-Code Generator schreibt aus der Spec Go-Code für ein CLI-Tool.
4. Go Compiler kann dir dann drei CPU-Architekturen mal drei Ziel-OS oder so erzeugen, schön statisch gelinkt.
5. Alle knapp Dutzend Binaries können für alle möglichen Kunden und Einsätze einfach auf einen Schlag released werden.

Und das alles auf derselben CI-Instanz.

[Exxtreme]

OK, Crosscompiling für GraalVM geht offenbar mit Github Actions:
https://blogs.oracle.com/developers/post/building-cross-platform-native-images-with-graalvm

[The_Invisible]

Einfach mehrere CI Instanzen?

[Marscel]

Ja, Github Actions, aber a.) Hab ich die vielleicht nicht zur Verfügung, b.) ist das evtl. ein Kostenfaktor, Mac-Minutes waren zuletzt ein paar Größenordnungen teurer, c.) muss ich ggf. drei Setups schaffen – auch wenn der Blogpost das da schon etwas vorkaut.

Go says: What?

[The_Invisible]

Ok wir haben eigene ci Instanzen, mit gitlab geht das ganz leicht inkl. Deployment in kubernetes cluster

[SimonX]

Hast du Erdbeertörtchen erwartet? :confused:



Wo ist da das Problem und was wolltest du da stattdessen haben?

Diese Beispiele zeigten mir das Go keinen Mehrwert hat.

Extrembeispiel: maps

Implizit immer als Referenz übergeben und somit ein Problem für Änderungen nach dem Übergeben. Im Gegensatz zu arrays...

Naja, es gibt seit 2023 maps.Clone obwohl google zu dem Thena immernoch Code Snippets von so 30 Zeilen findet.

Diese Inkonsistenz in Go zeigt doch, dass da was in den Grundkonzepten fehlt.

[Marscel]

Diese Beispiele zeigten mir das Go keinen Mehrwert hat.

Extrembeispiel: maps

Implizit immer als Referenz übergeben und somit ein Problem für Änderungen nach dem Übergeben. Im Gegensatz zu arrays...

Naja, es gibt seit 2023 maps.Clone obwohl google zu dem Thena immernoch Code Snippets von so 30 Zeilen findet.

Diese Inkonsistenz in Go zeigt doch, dass da was in den Grundkonzepten fehlt.

Ja, das maps-Ding ist tatsächlich komisch gewesen.

Aber zum Rest: Kann mir doch als Nutzer in gewissen Rahmenbedingungen egal sein, was mit den dahinterliegenden Grundkonzepten ist.

"go", "defer" oder channels sind doch schön plump und einfach zu nutzen. Performance-Probleme waren jetzt mWn nicht inhärent dadurch gegeben, und die GC-Unterbrechungen wurden soweit optimiert, dass die Java-VM vor v11 oder so dagegen arm aussah.

Bei Node muss man sich wieder vor Augen führen, dass das aus der Single-Threaded-Ecke kommt und da ein anderer Evolutionsdruck herrschte.

Wenn ich Sprachen heute Rückständigkeit vorwerfen würde, dann dass sie z. B. kein rigides const-Management haben bzw. erlauben, wie etwa bei C++/Rust. Das ist immer noch in so vielen Sprachen nervig, dass man keine statischen Garantien bekommt (also nicht nur Runtime-Kram wie OperationNotSupportedException in Java), dass etwas eine Referenz auf ein Objekt/Container definitiv nicht bearbeiten wird. Ja, da kann man sich auf verschiedenen Arten mitunter anders helfen, aber Thema Bloat.

[myMind]

Dass Go jetzt nicht die Sprache mit den meisten Features ist, ist nicht nur offensichtlich. Es ist das zentrale Designziel von Go auf Features zu verzichten, um an Einfachheit zu gewinnen. Wie Marscel sagt: "schön plump". Daher zieht der Vorwurf "Go fehlt aber Feature XY" nicht, ohne nicht auch darauf zu schauen, ob man im Gegenzug etwas bekommt, was einem vielleicht wichtig ist.

Ein Beispiel wurde oben schon genannt. Ich kann problemlos für verschiedenen Architekturen compilieren. Aus der Ecke kommen so einige schöne Dinge die Go mitbringt.

Beispielsweise sind die Compilezeiten einfach der Hammer. Auch große Projekte sind praktisch instant compiliert.

Dass man sich in Go sehr schnell einarbeiten kann, würde ich aus der Praxis bestätigen. Einige Dinge sind zwar gewöhnungsbedürftig und zum Teil auch sehr gewöhnungsbedürftig. Aber der Umfang der Dinge die man lernen muss ist vergleichsweise klein.

Oder nehmen wir das Thema Updates. In Go ist das ... einfach kein Thema. Immer noch in 1.x und eine 2.x wird möglicherweise nie erscheinen. Alles abwärtskompatibel. Update-Aufwände: Nahe Null. Wo kriegt man das sonst?

In Bibliotheken hineindebuggen. Geht einfach.

Paketmanagement. Easy. Geht einfach.

Errorhandling. Hat noch Potential nach oben, aber endlich bekomme ich punktgenauen Kontext wo der Fehler liegt und die Fehlermeldungen haben auch einen Datenkontext. Also anders als bei Exceptions, wo ich häufig einen größeren Block umschließe und dann am Ende in 99,999% aller Fälle unterlassen wird den Fehler auch mit Kontext-Daten anzureichern, ist die Tendenz dies in Go zu tun weitaus größer, weil ich enger am Problem dran bin. Entsprechend ist die Eingrenzung von Produktionsfehlern um Größenordungen einfacher.

Garbage Collection / Memory Mangement: Angenehm unauffällig.

Open source: Keine Gefahr eines Vendor-Lockins.

Usw.

Go hat einige Verbesserungsschleifen hinter sich. Im jetzigen Zustand ist das schon sehr brauchbar.

Eine Sprache für alles halte ich aber auch für kompletten Unsinn. Ich würde dem Management eher vorschlagen dass man sich auf zwei oder drei Sprachen für bestimmte Zwecke konzentriert, je nachdem wo der Fokus eurer Firma liegt.

Ist es nicht ohnehin so, dass der Kontext in dem man sich befindet, die Sprachwahl stark einschränkt? Laufe ich in einem Browser? In einem bestimmten Betriebssystem? Muss ich "überall" laufen? Cloud? Embedded? Vendor-Lockin akzeptabel oder sogar automatisch gegeben, wegen Plattform? Wie ist die Lizensierung? Skalierbarkeit? UI? Brauche ich bestimmte Bibliotheken? Usw. Nachdem ich durch die Filter durch bin, ist die Sprachauswahl sowieso nur noch begrenzt.

Die zwei Dinge, die mich in Go am meisten stören ist einerseits die sehr überschaubare Refactoring-Unterstützung. Das kann auch an der IDE liegen, aber VSCode mit Go glänzt da nicht grade. Das andere ist, dass einige Bibliotheken sehr unintuitiv sind. Ich nenne da mal Rune und Time. Respekt wer das aus dem Stand richtig verwendet. Das finde ich an C# so schön. Dort findet man viele Libraries bei denen man exakt gar nicht nachdenken muss. Funktioniert genau so wie man das erwartet.

Weniger Features müssen aus meiner Sicht kein Rückschritt sein, wenn man im Gegenzug etwas bekommt. Ob das so ist, ist bei Sprachen schwer messbar. Erfahrbar ist das aber schon. Von daher >> ausprobieren. Sich darauf einlassen.

Ich merke auf jeden Fall, dass meine Neigung sich in Schönheit zu verkünsteln massiv abgenommen hat. Funktioniert auch ohne den 72. Wrapper um die drölfte Abstraktionsschicht. Ob die Anwendungen dadurch jetzt wirklich immer besser werden ist schwer zu sagen.

[SimonX]

Für mich zählt die Einfachheit und Freiheit beim Entwickeln.

Go ist vielleicht barebone aber nicht einfach.

Als erstes habe ich ein nutzbares Errorhandling mit stacktrace umgesetzt und einem Unterbau, der beliebige daten mit namen transportieren kann, und projektzentrale uniq errors mit definierten parameter. Dadurch brauche ich nicht immer custom error code, sondern muss nach jedem func call meistens nur noch das ife<tab> vscode editor snippet in den code einfügen mit händischem ersetzen von return nil,err durch z.B. return nil,stderr.Http(req,rsp,err). Der error kann dann an der richtigen stell ausgegeben. (Nicht jeder error ist auf einer höheren ebene noch ein error oder wert geloggt zu werden. Nicht jeder lowlevel error kann ohne die call hierachy verstanden werden.) Habe für errorhandling kein package gefunden. Nur code snippets.

Das man zu jeder func gleich immer 3 zeilen braucht ist hart.
Das goto's als catch alternative angesehen werden ist böse.

Compiletime interessiert nicht, wobei ich den compiler für langsam halte. Braucht eine ewigkeit (10s? Für aktuell wenig code) zum debuggen. Bin da ein instant debug von typescript gewöhnt.

Das package system ist kein alleinstellungsmerkmal. Ist mindeststandard. Ohne wären wir wirklich in den per 2010'er jahren.

Das bei API Beschreibungen die attribute gross geschrieben werden müssen um sie dann im meta klein zu schreiben damit sie der api entsprechen ist sowas von tipparbeit. Oder gibt es für sowas ein package?


Obwohl Go barebone ist hat es doch einige unnötige Sachen:

- Wer braucht das Grossschreiben um zu exportieren?

- Das mit der Map hatte ich schon geschrieben. Zeigt mir das Go nicht mal eigene basics sauber abbilden kann.

- struct erfüllt interfaces ohne das mal zu sagen. D.H. das man sieht vom code nicht welche interfaces die struct erfüllen sollte.

- struct ist nur ein passives object aber sonst das gleiche. Den constructor darf man ja ohne language support aber mit namenskonvention selbst schreiben.

- package ist ein globales object mit constructor (init) aber ohne destructor (oder habe ich was noch nicht gelernt?). Ist nicht unnötig, aber zeigt selbst in go die existenzberechtigung von objects.

- Die wenigen Feature von Go machen das Entwickeln nur schwerer

- In packages reindebuggen ist standard. Schalte ich immer ab weil es nerft. Muss noch das passende vscode setting für go finden.

- Vorsicht open source != no vendor lock. Wir machen ein license clearing


PS:

Dafür das Node single threaded ist, kann man aber einfach auf 1000'te Sachen gleichzeitig warten und 1000'den parallelen deep inline-contexten unterwegs sein. Standard in Frontend wie auch im node backend, nur eine magnitute kleiner.

Die einfachheit des parallelen wartens in node fehlt mir in go. Das poll loop konstrukt ( select + waitgroup ) ist kein ersatz. Wann muss man schon parallel rechnen? Bei uns auf jeden fall sehr selten.

[Aquaschaf]

Was hat die Firma denn vorher eingesetzt? Golang sollte eine modernere/sicherere Alternative zu C/C++ sein, und eben konzeptionell möglichst einfach. Das Design-Ziel erfüllt die Sprache. In Rust kann man eleganteren Code schreiben, aber dafür ist die Sprache wiederum komplexer.

Wenn man in Golang Sachen programmiert die man auch mit Typescript / NodeJS oder einer anderen High-Level-Sprache bauen könnte, dann macht das natürlich keinen Spaß und auch recht wenig Sinn. Für die gleiche Funktionalität braucht man wahrscheinlich 2x-3x so viele Zeilen Code.

[samm]

Go hat es massiv erleichtert, einen schönen und teamübergreifenden Workflow hinzukriegen - keine trivialen aber nervtötenden Zusammenarbeits-Issues wie Formattierungsdifferenzen zwischen IDEs oder individuellen Devs, keine Umwege für Tests, Fuzzing, Benchmarking, Profiling.

Ausserdem inhärent einfach handzuhabende Nebenläufigkeit mit vielen Abstraktionen ootb verfügbar. Unser Projekt hat so viel wie möglich parallel laufen lassen müssen, manchmal mit Kommunikation (channels), manchmal mit warten, manchmal mit Fire-and-Forget. Alles easy ohne Kopfzerbrechen, ohne schwere Thread-Starts usw.

Der ebenfalls notwendige komplette Offline-Workflow ging soweit ganz gut mit einem lokalen Artifactory und einem leider notwendigen offline-packager-Tool, womit die notwendigen Pakete+Dependencies aus dem Netz bezogen und ins Artifactory hochgeladen werden konnten.

Multiplattform-Rollout der resultierenden Binaries war schmerzlos, die plattform-abhängigen Stellen easy und klar handhabbar.

Nein, nicht rückschrittlich. Leicht zu benutzen. Leicht zusammenzuarbeiten. Leicht parallele Abläufe zu erstellen.

Ich würde gerne wieder in Go arbeiten, aber leider bin ich aktuell auf dem Klotz "Java" unterwegs. Was für ein träges, überladenes Monster, das im aktuellen Umfeld komplett durch Frameworks noch fetter und sehr framework-spezifisch zu nutzen ist.

[edit]
omg, das architekturelle Killer-Thema hab ich noch ausgelassen: Inhärente Dependency-Inversion durch die Art, wie in Go Interfaces funktionieren. Einfach top.

Und ist Pest eigentlich noch aktiv? Wenn ich den Guten nicht verwechsle (was durchaus sein könnte) müsste er auch einiges Gutes drüber zu sagen haben

[SimonX]

Nach vielen Wochen entwickeln in Go kann ich sagen, was das schlimmste an Go ist:

- Die crude inkonsistente Syntax mit ihren impliziten Sonderlocken.
- Die Unmöglichkeit normale und einfache Sachen als 1-Liner zu schreiben.
- Das Fehlen von Packages die ansonst standard High-Level Features von Hochsprachen abbilden.

[Ganon]

Wobei es mittlerweile recht normal ist, dass man die grundlegende Sprache nicht mit einer umfassenden Standardbibliothek "vollmüllt". Z.B. auch Rust hat so gut wie keine Standardbibliothek.

C++, Java und .NET haben gezeigt, dass man damit auf lange Sicht auch so seinen Ärger damit hat und man eben zusätzlich zu dem neuen Kram auch all den alten Ballast mitschleppen oder neue Versionen ohne Kompatibiltät für alte Anwendungen rausbringen muss. Am Ende hat man dann langwierige Deprecation-Prozesse und/oder mehrere unterschiedliche Implementierungen der gleichen Sache (z.B. Java: Date, Calendar, LocalDate und Co., IO <> NIO, Java 1.0 Collections vs Java 1.2+ Collections).

Hat sicherlich alles Vor- und Nachteile. Sprachänderungen haben auch so ihren Fallout. Siehe die ganze Geschichte rund um Python 2, die immer noch nicht vollständig abgeschlossen ist. Diverse Firmen hängen auch noch auf Java 8, weil spätere Versionen bestimmte Dinge abgeändert haben.

Man ist halt einfach flexibler und kann das Problem lokal angehen. Auf der anderen Seite ist die Paketsuche natürlich erst mal ein höhrer initialer Aufwand für den Entwickler, klar.

[SimonX]

Bezüglich Sprachänderungen:

Seit go 1.22 (Feb-2024) experimental, obwohl ich das auch ohne compiler flags nutzen und bauen kann. Der Linter sagt auch nichts. (Noch nicht getestet ob es wirklich funktioniert)

for i:=range 100 {
fmt.Println(i)
}

Gibt 0-99 aus (oder doch 1-100? hoffe 0-99)

Da wird auch am Sprach-Core von Go gespielt.

[samm]

Nach vielen Wochen entwickeln in Go kann ich sagen, was das schlimmste an Go ist:

- Die crude inkonsistente Syntax mit ihren impliziten Sonderlocken.
- Die Unmöglichkeit normale und einfache Sachen als 1-Liner zu schreiben.
- Das Fehlen von Packages die ansonst standard High-Level Features von Hochsprachen abbilden.Von Go zurück nach Java und Typescript kommen befinde ich Punkt 1 dort wesentlich schlimmer. Go hat ein paar wenige erstmal gewöhnungsbedürftige Syntax-Aspekte, aber die beschränkten sich mMn auf abgekürzte if-Checks mit Strichpunkt und die Channel-Notation.

Punkt 2 ist andersrum grauenhaft für die Einarbeitung und Reviews - lieber ich brauche zwei Zeilen, dafür versteht jeder, was passiert, als dass ich ne grässliche Perl-Verkettung für Profis hinbastle, um Zeilen zu sparen.

Punkt 3 ebenfalls, andersrum grauenhaft. Sowohl Java-Frameworks wie auch praktisch alles Web-basierte zieht pro Package dermassen viel Dependencies mit sich, das ist nicht mehr feierlich. Lieber ein, zweimal ein simples Rad neu erfinden als sowas.

Zusammengefasst sehe ich alle drei Punkte als klare Sprach-Eigenheiten, die Bewertung davon ist aber subjektiv und nicht absolut gesehen schlecht.

Bezüglich der Range-Loop, da ich keine solche Indexzählereien gemacht habe, ist mir die Änderung hier nicht klar, aber wenn das ein breaking change innerhalb einer Revision ist, ist das auch aus meiner Sicht sehr schlecht.

[edit]Okay, gegoogelt zur for i := range 100. Das ist schlicht eine neue, keine Änderung bestehender, Funktionalität.

[Badesalz]

Immer wieder bisschen seltsam wie groß der Anteil an Leuten ist die sich nahezu vollständig drauf fokussieren wie schnell sie zu etwas kommen was auf dem Bildschirm anscheinend tut was es soll, und alles andere bestenfalls drittrangig ist.

Von Leitner hat sich damit auch mal beschäftigt. Den Artikel kann ich immer schnell finden, weil ich mir 2 Thesen gemerkt habe:
"Es gibt in der Softwareentwicklung mehrere fundamentale Probleme und Hindernisse, und keines davon ist technisch."

"Programmieren ist in der Praxis eher ein Optimierungsproblem (was ist der geringste Aufwand, den ich treiben muss, damit der Kunde mir das abnimmt) als eine konstruktive Ingenieurskunst.
Schlimmer noch: Wenn man einen Programmierer findet, der alles ordentlich machen will, dann ist der im Markt nicht konkurrenzfähig gegen die ganzen Abkürzungen der Pfuscher der Konkurrenz."

https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

D.h. ihr gebt mir Software deren Entwicklung für euch selbst vermeintlich alles einfacher machte (in eurem Kontext ein Synonym für schneller bis zu Kundenbeta, nicht für besser) - da ihr anscheinend alle >55 seid und keine Zeit mehr fürs Lernen verschwenden wollt - und die dann bei mir für das Ergebnis mit allen zusammenhängenden Nachteilen neben der Zeit, 4x länger läuft als nötig?
https://blog.logrocket.com/when-to-use-rust-when-to-use-golang/
Und jubelt euch gegenseitig zu? Warum macht ihr dann nicht gleich PyPy? Aber hej, wie soll der Kunde das denn mit dem 4fach Slowmo mitbekommen...? Ist schon ok...


PS:
Jahre über Jahre + ewig und 3 Tage, haben mich alle drumherum nur gemobbt :D weil ich die Unverschämtheit und auch die Power hatte/habe, (dank einer quasi bedingungslosen Unterstützung von oben), zu behaupten und zu bestimmen, daß wenn wir was ordentlich vorhaben, wenn schon in C, wir nur "Ansi-C" machen. Punkt. Ein Hoch auf mich :wink:
https://blog.fefe.de/?ts=9bc148ba

Anhand dieser ähh... schmerzhaften Grundlage und jenes überaus langen Atems, wurde mein Vorschlag, als Alternative dazu, sich ab 1.61 nun so langsam Rust ernsthafter anzuschauen, geradezu frenetisch bejubelt :tongue:
Egal wie lange ich rumgelaufen bin, ich fand niemanden der was dagegen hätte und nicht bereits fleißig am pauken wäre :wink:

[Marscel]

...

Worauf willst du hinaus? Wenn man irgendeinen Kram schreiben muss, dessen Hauptaufgabe z. B. darin liegt irgendwas stapelweise auf dem I/O zu irgendeiner unbekannt fitten Gegenstelle per HTTP zu schicken oder erwarten, dann erübrigen sich vermutlich ohnehin irgendwelchen Sprachdiskussion über das Argument, dass das eine im mandelbroten schneller ist. Die Zeit, die ich in C damit beschäftigt bin, Strings fehlerfrei zu allocaten und zu concatenaten, also ohne von irgendeinem doofen off-by-one Fehler oder sowas im Nachbarspeicher zu laden und einen Kunden damit einem Risiko auszusetzen (curl ist da so ein Beispiel), steht bestimmt nicht im besseren Verhältnis zu mal eben Go für den selben Zweck zu nutzen.

Und Rust ist da am Anfang wirklich kein kurzer weg, das sag ich aus Erfahrung, also muss auch das sich nach hinten bewähren, wirtschaftlich.

Tja, und jetzt arbeitest du irgendwo, wie von Fefe geschrieben, wo du mit dem Budget auskommen musst, oder die mittelfristige Zukunft sehr offen ist, da kannst du dann auch überlegen, womit du zum Ziel kommst.

Und ab davon gibt es etliche Fehler, die dir Performance sehr viel schneller brechen und mitunter nichts mit der Sprache oder der Runtime zu tun haben: Datenbank kriegt keinen (genutzen) Index, irgendwo wird jedes Byte einzeln abgerufen und geschrieben, jemand kam nicht auf die Idee etwas zu streamen, irgendwer hat Bubblesort nachgebaut, wieder jemand anderes macht in einer Schleife immer und immer wieder denselben, invarianten Kram ...

[Badesalz]

Und Rust ist da am Anfang wirklich kein kurzer weg Jemand hier hat mal festgestellt, daß es so ähnlich ist wie 15 Jahre Taxifahrer in Ägypten, dann in die Schweiz ziehen und weiter im gleichen Beruf arbeiten wollen :uup:
Ja. Es ist eine Umstellung... Wenn man sein halbes Leben aus der technischen/technologischen Sicht nur Larifari kennt und dann plötzlich alles nur noch auf dem einzig und alleine 100% korrekten Weg erledigt werden will, dann ist man damit nicht in einer Woche durch. Wenn man früher von Pascal auf C ging war das übrigens auch so.

Wir haben uns noch ne Weile mit "Oxidation" beigeholfen. Nach einem Jahr sitzt ich in einer kurzen Besprechung (wir halten keine Meetings ab :tongue: ) und höre wie einer der Projektleiter beiläufig sagt, daß sie diesen Monat gerne noch nicht zu andere Soft etwas beitragen würden, weil sie in ihre aktuelle Soft noch 5 Tumore haben und das unbedingt erst loswerden möchten.
Ich leider ahnungslos, also frag ich nach der Besprechung klammheimlich jemanden was bei uns bitte Tumore sind :redface:

Tumore sind bei uns im Flursprech alle nicht-Rust Codeteile, ausgenommen ASM -> mission accomplished :naughty:

Sonst bleibt alles so wie es eben in #32 steht. Wie kontextrelevant dazu folgende Beiträge sind muss der geneigte Leser für sich selbst entscheiden.

edit:
Und ja. Wenn man C in Rust programmiert :usweet: dann läuft das oft, rennt aber nicht. Das wird aber noch :wink:
https://stackoverflow.com/questions/70672533/why-does-iteration-over-an-inclusive-range-generate-longer-assembly-in-rust-than
https://kornel.ski/rust-c-speed (ohne Datum...)