F# – Zeit für den Abschied?

Als ich vor knapp sechs Jahren über dem Technologie-Stack des Projektes grübelte, das später Taxaro werden sollte, hatte ich für die Webapplikation neben Exoten wie Reason und Elm vor allem TypeScript und F# in der Auswahl. Die ersten beiden kamen schon damals wegen ihrer geringen Verbreitung nicht wirklich in Frage und letztlich entschied ich mich damals auch weniger für TypeScript als gegen F#, weil ich nicht an das F#-Ökosystem im Frontend-Kontext glaubte. Ich sollte recht behalten.

Dennoch habe ich F# genutzt und tue das heute noch – im Backend. Und ich muss ehrlich sagen: Ich bin so verliebt in die Sprache und die Art zu programmieren wie am ersten Tag. Wann immer ich in den letzten Jahren nur daran dachte, an der Codebasis arbeiten zu können, überkam mich ein wohliges Gefühl. Das klingt schwülstig, irrational und ist es vermutlich auch – aber es hat mir schlicht stets nichts als Freude bereitet. Während ich die Arbeit am React-Frontend mit TypeScript stets unemotional betrachtet habe. TypeScript hat ein paar funktionale Konzepte, aber es ist aus meiner Sicht deutlich zu „verbose" und irgendetwas fehlt. Genau wie bei Dart, das ich für die Taxaro-Mobile-App nutzen muss.

Aber es hat sich etwas geändert, insbesondere im letzten Jahr. Seit Mai 2025 nutze ich Claude Code, mein Token-Verbrauch allein in den letzten 30 Tagen lag bei 775 Millionen.

Ich schreibe immer weniger Code selbst. Zwar reviewe ich fast alles, was generiert wurde, derzeit noch und behalte mir auch die Git-Commits vor, aber auch das sehe ich mittelfristig potenziell verschwinden. Ich habe zuletzt auch deshalb nichts zu meiner Arbeitsweise mit Claude Code und Codex veröffentlicht, weil diese sich gefühlt alle 2–4 Wochen ändert und weiterentwickelt. Auch die Zunahme an Fähigkeiten der Tools selbst ist atemberaubend.

Kurzer Exkurs: Gestern wollte ich in Sentry aufgelaufene Crashes der Taxaro-Mobile-App bearbeiten. Früher wäre ich die Logs durchgegangen, hätte Tickets erstellt und da Stacktraces reinkopiert. Dann hätte ich ein paar Tage zugeschaut, wie die Tickets vom Team bearbeitet werden und durchs Board wandern. Nun kam mir der Gedanke, dass das doch auch Claude können müsste. Stellt sich heraus: Kann es. Mittels Plugin und MCP-Server konnte ich schlussendlich sagen: Schaue alle Crashes durch, schlage Lösungen vor und setze diese um. Kurzes Review, Commit, Build, Deploy, done. Nach einer halben Stunde war alles erledigt. Der Engpass ist jetzt nicht mehr unser interner Prozess, sondern das Review von Apple.

Was hat das nun mit F# zu tun? Nun, mit der Veränderung der Arbeitsweise nimmt auch die Häufigkeit ab, mit der ich meine IDE offen habe. Was sich mit den Berichten anderer deckt – David Fowler von Microsoft hat bspw. kürzlich geschrieben, dass er zuletzt das „große" Visual Studio kaum noch genutzt hat, weil er primär Code generieren lässt.

In meinem Fall ist die IDE Rider von JetBrains, ohne die ich mir nicht vorstellen kann, überhaupt mit F# zu arbeiten. Visual Studio für Windows kommt (wegen Windows) nicht in Frage, Visual Studio für Mac gibt es nicht mehr und Ionide, das Plugin für Visual Studio Code, war historisch buggy. Meine „Developer Experience" hängt also vom F#-Plugin in Rider ab. Einem Plugin, das vermutlich von ein oder zwei Leuten in Teilzeit gepflegt wird, für eine IDE, deren wirtschaftliche Zukunft zumindest mal mit Fragezeichen versehen ist. Wenn man diese „full-blown" Entwicklungsumgebungen kaum noch braucht, weil ein Editor und ggf. ein Git-Frontend reichen, was wird das für ihre Entwicklungs-Budgets bedeuten? Ich fürchte nichts Gutes.

Ich werde deshalb nicht das bestehende F#-Backend von Taxaro portieren. Aber ich werde den Gedanken in die anstehende Technologieentscheidung für ein neues Produkt mit einfließen lassen. Und mich dann wahrscheinlich für etwas entscheiden, was eine breitere Basis hat bzw. für das ein einfacher Editor genügt. TypeScript zum Beispiel.