Markus Zander

Im Juni 2025 haben die Go-Maintainer eine Entscheidung getroffen, die auf den ersten Blick wie Aufgeben aussieht - und auf den zweiten wie Reife. Seit Jahren stört sich die halbe Go-Community an einer Sache: der Fehlerbehandlung. Nach fast jedem Funktionsaufruf dieselbe Geste: `if err != nil { return err }`. Drei Anläufe in sieben Jahren sollten das beheben: erst das check/handle-Modell aus dem Go-2-Entwurf, dann die try()-Funktion, zuletzt ein „?"-Operator nach Rust-Vorbild. Keiner hat es in die Sprache geschafft. Im Juni 2025 zogen die Maintainer einen Schlussstrich: keine neue Syntax für Fehlerbehandlung, die offenen Proposals werden geschlossen. Die drei Zeilen bleiben. Der elegante Gegenentwurf Java löst dasselbe Problem scheinbar schöner. Eine Methode wirft eine Exception, irgendwo weiter oben fängt sie jemand. Dazwischen muss niemand etwas tun. Checked Exceptions sollten genau das erzwingen: der Compiler verlangt, dass man sich kümmert. In der Praxis endet das oft in ein...

Diese Woche gab es bei uns eine Diskussion, die in keinem Feature-Plan steht und trotzdem über Jahre nachwirkt: Wie gehen wir mit dem Support für die ältere Generation eines Produkts um, wenn die neue längst im Einsatz ist. Keine Frage, die man auf einer Folie schön darstellen kann. Aber eine, die jeden Betrieb früher oder später einholt. Legacy ist kein Zustand, sondern eine Entscheidung Der Begriff Legacy klingt nach Staub und Stillstand. Tatsächlich ist Legacy meist das, was zuverlässig läuft und Geld verdient. Das Problem ist nicht der alte Code an sich, sondern die fehlende Entscheidung, wie lange und wie gut man ihn noch trägt. Gartner beziffert das: Wer technische Schulden ignoriert, gibt bis zu 40% mehr für Wartung aus. Premium-Support für End-of-Life-Systeme kostet schnell das Doppelte bis Dreifache des regulären Supports. Wer nichts entscheidet, entscheidet sich für die teuerste Variante. Die alte Generation ist ein Vertrauenstest In der Enterprise-Welt laufen Anwendungen...

Acht Stunden Outage gestern Nacht. Mein Go-Stack auf Railway war nicht erreichbar - das Frontend lief, das Backend war tot. Ursache: Google Cloud hat Railways Produktions-Account fälschlich in einen Suspend-Status verschoben. Automatisierte Aktion, keine Vorwarnung, und eine Reihe weiterer Kunden traf es im selben Schwung mit. Was PaaS verspricht - und was nicht Railway, Render, Fly.io und Konsorten verkaufen Developer Experience. Push-to-deploy, automatische Build-Pipelines, fertige Datenbanken. Das ist real und gut. Was sie nicht abstrahieren: die Infrastruktur unter der Plattform. Railway läuft auf GCP. Wenn dort ein Compliance-Filter falsch konfiguriert ist, geht Railway offline. Ohne Vorwarnung, ohne Eskalationspfad für den einzelnen Kunden. Die Lieferketten-Frage Vor fünf Jahren war „auf welchem Cloud-Provider seid ihr" eine sinnvolle Frage. Heute braucht es zwei: Auf welchem Provider seid ihr direkt - und auf welchem Provider sitzt eure PaaS? Bei vielen Java-Stacks ist ...