Ein wirklich gutes und informatives Video!! Ich muss gestehen ich habe mich auf Basis eurer Videos auch Mal in go eingelesen und bin sehr positiv angetan!! Danke für den schönen Denkanstoß an die Sprache GO! 🙏👍
Vielen Dank, extrem lehrreich und habe euch schon ein paar mal Weiterempfohlen! Die Einbindungen sind wirklich smart, habe darüber einen Apache Tika Server (Java) integriert, da es für Go leider noch nicht so gute eigene Lösungen gibt um PDFs auszulesen insb. bei Bankdokumenten.
Für mich ist pprof eine solche Perle. Es ist so einfach ein CPU oder Memory Profil zu erstellen, so dass wir uns während der Entwicklung praktisch nicht um die Performance kümmern. Zunächst gilt es einfachen, korrekten und gut getesteten Code zu schreiben. Erst wenn es ums Release geht, optimieren wir auf Basis von pprof. Das stellt auch sicher, dass wir uns nicht auf vermeintliche Schwächen konzentrieren, sondern dort angreifen, wo es tatsächlich weh tut.
Hi Golo, Ich bin auch go-Entwickler und würde von mir behaupten dass ich mittlerweile alles recht idiomatisch in Go umsetze. Dennoch hab ich ein Problem mit den http-request Tests. Ich weiß nie wie es dort optimal ist Tests zu formulieren, wenn man komplette die response assertet, sollte man vermutlich im Interesse der langen Frist sowas wie Mitchell Hashimoto in ˋAdvanced testing with goˋmachen und eine Art Update flag der Test fixtures anbieten. Das macht mehr Aufwand und den Test komplizierter (für Ensteiger). Aber der Test bleibt zuverlässig. Auf der anderen Seite könnte man wie du es vorschlägst auch nur den StatusCode prüfen. Kannst Du vielleicht erzählen wie ihr damit umgeht? … Vermutlich kommt drauf an 😂
[gr] Danke für Dein Lob 😊 Ein Backend-Framework nutzen wir bislang gar nicht - lediglich für das einfachere Routing github.com/julienschmidt/httprouter, aber insbesondere kein ORM.
[gr] Haha - beim Lesen Deines Kommentars bildete sich in meinem Kopf der Satz "naja, es kommt darauf an…" und dann kam Dein letzter Satz 🤣 Es kommt halt insofern "immer darauf an", was einem wichtig ist beziehungsweise was man sicherstellen möchte. Bei einer HTTP-API sehe ich das erst mal recht pragmatisch: Gibt sie den richtigen Statuscode zurück? Stimmt der Content-Type-Header? Bzw, falls es ungewöhnliche Header gibt, stimmen die auch? Stimmt der (exemplarische) Inhalt einer Response? Das hält sich IMHO vom Aufwand her in Grenzen, und so testen wir im Großen und Ganzen auch seit ~10 Jahren unter Node.js mit Express, womit wir bislang sehr gute Erfahrungen gemacht haben. Den genannten Talk kenne ich nicht vom Inhalt her - wo wären denn an der Stelle die Bedenken?
Es ist toll, wie schnell man in Go produktiv wird! Allerdings ist das Fehlerhandling echt gewöhnungsbedürftig... Option und Result + Error Propagation über den ? Operator wie in Rust würde ich auch gerne in Go sehen!
In 08:11 sagst du, dass das Test Filesystem nur read-only ist. Nur beim Setup definiert man die Inhalte einmalig - ab dann ist es ro. Aber einen read-only Test kann ich doch auch einfach mit dem realen FS machen ohne Aufzuräumen; es ist so vielleicht etwas langsamer; aber was gibt es sonst als Vorteile?
[gr] Das ist richtig - aber ein In-Memory-File-System ist viel einfacher aufzusetzen als einen Ordner anlegen, Dateien ablegen, richtig befüllen, und dann nachher wieder aufräumen müssen. Alternativ kannst Du das zu testende Verzeichnis natürlich mit einchecken, aber wenn Du jetzt verschiedene Szenarien testen willst, was ist, wenn Datei X fehlt, was, wenn Datei Y fehlt, … dann wird das schnell sehr viel und sehr unübersichtlich. Da ist dann ein In-Memory-File-System schon einfacher und komfortabler zu handhaben.
Direkt zum ersten Thema: Ein gutes Beispiel ist auch, dass Go in der Standardbibliothek meines Wissens nach kein streng monotones Zeitsystem bietet. Es ist also nicht möglich anhand der mitgelieferten Bordmittel mittels der Zeit garantiert zu sagen welches Event zuerst passiert ist. Um das umzusetzen muss man eine Dependency nutzen.
[gr] Ein tatsächlich streng monotones Zeitsystem ist auch gar nicht so leicht umzusetzen, weil man dann ja zB Korrekturen an der Uhr nicht übernehmen darf (die Uhr könnte ja zurück-korrigiert werden). Das ist auch ein Grund, warum logische Uhren gar nicht mit echter Zeit arbeiten, sondern im Prinzip nur mit Zählern.
@@thenativeweb Das ist absolut korrekt, dass streng monotone Zeitsysteme hart sind, aber alle Betriebssysteme bieten dafür ja APIs (die unter Anderem auch Go intern nutzt, aber nicht ideal verfügbar macht). Rust unterscheidet hier z. B. zwischen std::time::SystemTime (nicht streng monoton) und std::time::Instance (streng monoton). Go hat vor Version 1.9 streng monotone Zeiten gar nicht unterstützt und man brauchte Pakete wie monotime. Seit 1.9 wurde einfach das verhalten des internen Moduls "time" verändert, was auch viel Chaos ausgelöst hat und bedeutet, dass auf unterstützten Plattformen in Go ein time::Time jetzt eine Wall und eine Monotonic Time enthält (die auch noch nacheinander abgerufen werden). Meiner Meinung nach eine sehr unelegante Lösung.
Der Context hört sich nicht nur nach AbortController/-Signal, sondern auch nach CancellationToken(-Source) an. War nach der Einleitung etwas hyped und dann leicht underwhelmed, dass sie auch nur das gleiche in grün machen.
[gr] Ja, der Context ist auch ein Cancellation-Token (er kombiniert einiges, wofür Du in JavaScript mehrere Konstrukte brauchst), und er ist halt seit Jahren "einfach da", wohingegen das in JavaScript viel länger gedauert hat und dann jetzt ein ziemliches Stückwerk ist.
Bin von Go bisher nicht so sehr überwältigt, aber auch nicht enttäuscht. Es macht vieles richtig, aber es erfindet das Rad jetzt auch nicht neu. Hab in meinem Fall jetzt keinen wirklichen Anwendungsfall feststellen können, weil ich ein gigantischer Fan von einer einzigen CodeBase bin. Das schafft bisher nur JS / TS, wenn es um den Bereich Web und Cloud geht und da halten wir uns hier wahrscheinlich alle irgendwie auf. :P Wenn ich mal was mehr Performance brauche, dann bediene ich mich einfach bei AssemblyScript. Damit behalte ich meine Codebase und habe trotzdem WebAssembly-Geschwindigkeit. Vielleicht auch etwas für euch? Wichtig dabei ist: AssemblyScript ist KEIN TypeScript, auch wenn es so aussieht. Es ermöglich einen aber trotzdem in der selben Codebase zu bleiben. =)
[gr] Danke für Deinen Kommentar, und den Hinweis auf AssemblyScript 😊 Prinzipiell finde ich das auch eine interessante Entwicklung, aber da sind wir (für uns) wieder bei dem Punkt, dass auch das nicht ohne Laufzeitumgebung läuft.
