// HEISE ONLINE — HARDWARE & GADGET
Werkzeugwahl, Teil 1: Wenn Agenten schreiben, verlieren Sprachen an Bedeutung
Der Rails-Erfinder lässt das HEY-Backend von Agenten in Rust schreiben. Ich finde das richtig: Sprachen verlieren an Gewicht, es zählt, was sich prüfen lässt.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Ende September hat David Heinemeier Hansson auf der Rails World eine Keynote gehalten, über die die Ruby-Community noch lange sprechen wird. Ausgerechnet der Erfinder von Ruby on Rails verkündete, dass das Backend der nächsten Version seines E-Mail-Dienstes HEY nicht mehr auf Ruby basiert, sondern auf Rust. Geschrieben hat er es nicht selbst, sondern mithilfe von Coding-Agenten.
Rust sei zwar eine ästhetisch schreckliche Sprache, aber das sei egal: Er schaue sich den Code ohnehin nicht mehr an. Die schönste Programmiersprache der Welt sei nämlich nicht Ruby, sondern Englisch. Im Saal saßen rund tausend Entwicklerinnen und Entwickler, und es wurde still.
Meine erste Reaktion fiel anders aus: Er hat nicht unrecht. HEY ist keine Raketenwissenschaft, sondern eine Anwendung, deren Code technisch überschaubar ist, und genau solchen Code können Agenten heute ziemlich gut erzeugen. Warum ich der These im Kern zustimme, was sie über die Wahl von Programmiersprachen verrät und wo sie aufhört zu gelten, darum geht es in diesem ersten Teil einer zweiteiligen Serie über die Werkzeugwahl.
Wie weit dieser Schritt reicht, zeigt ein Blick in die Rails-Doktrin, die Hansson selbst verfasst hat. Ihr erster Grundsatz lautet „Optimize for programmer happiness“ und er beschreibt die ursprüngliche Ketzerei von Ruby: das Wohlbefinden derjenigen, die programmieren, auf ein Podest zu stellen. Ruby sollte sich gut anfühlen, Rails sollte Freude machen, und für sehr viele Entwicklerinnen und Entwickler hat genau das jahrelang funktioniert.
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Dieses Kriterium ist keine Eigenheit der Ruby-Welt, es steckt in fast jeder Diskussion über Programmiersprachen. Wer zwischen zwei Sprachen wählt, fragt fast immer auch, wie es sich anfühlt, darin zu arbeiten: wie elegant die Syntax ist, wie viel unnötiges Drumherum nötig ist, wie schnell aus einer Idee lauffähiger Code wird, und so weiter. All das sind Eigenschaften des Schreibens – und sie richten sich an den Menschen, der schreibt.
Schreibt jedoch nicht mehr der Mensch, verliert das Kriterium seinen Adressaten. Einem Agenten ist es nämlich gleichgültig, ob eine Syntax elegant ist: Er empfindet weder Freude noch Verdruss. Deshalb sehe ich in Hanssons Entscheidung keinen Bruch mit seiner eigenen Doktrin, sondern ihre konsequente Fortsetzung. Wenn das Glück beim Schreiben keine Rolle mehr spielt, darf es auch die Wahl der Sprache nicht mehr bestimmen.
Was übrig bleibt, sind die Eigenschaften des Ergebnisses. Bei Rust sind das vor allem die Garantien des Typsystems, die Performance und der geringe Ressourcenverbrauch. Laut Hansson lässt sich die Zahl der Server für das HEY-Backend auf zehn reduzieren, und selbst das nur wegen der Ausfallsicherheit. Nach seiner Bauchgefühl-Rechnung würde sogar ein einzelner Raspberry Pi genügen. Ob das im Detail stimmt, sei dahingestellt. Die Richtung ist aber eindeutig – und sie hat herzlich wenig mit Ästhetik zu tun.