LLMs machen Sprachenwahl nebensächlich – und Rust & Zig profitieren
Fast and Hard Code
Armin Ronacher, langjähriger Rust-Programmierer, beobachtet einen Wandel: KI-Agenten ebnen den Weg für „harte“ Sprachen wie Rust und Zig, selbst für Entwickler ohne tiefe Sprachkenntnisse. Projekte wie Cloudflares Artifacts (reines Zig, ~100 KB WebAssembly) und Vercels fx-Agent zeigen den Trend. Auch exotische Technologien wie DWARF, eBPF oder eigene Krypto-Implementierungen werden dank LLM-Unterstützung zugänglicher. Ronacher sieht darin eine Chance für mehr schnelle und kompakte Software – trotz möglicher „Slop“-Flut.
All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware.
- qsera
> Plötzlich habe ich Leute gesehen, die wirklich beeindruckende Sachen mit DWARF-Dateien, eBPF, eigenen Netzwerktreibern, eigener Kryptografie und wirklich alter Computerhardware gemacht haben. Viele dieser Dinge waren für viele Entwickler zuvor tabu. In manchen Fällen (z.B. Krypto) wurde man sogar abgewiesen, weil diese Dinge absichtlich von den Eingeweihten abgeschottet wurden.
Vorher waren zumindest einige von uns gezwungen, Dinge zu verstehen, weil es ohne Verständnis nicht möglich war, Dinge zu tun, die wir wirklich tun wollten, und einige davon wurden leidenschaftlich und gruben weiter, und einige von uns machten sogar noch bessere Dinge auf der Grundlage ihrer Erfahrung.
Jetzt muss niemand mehr irgendetwas verstehen, und jetzt werden wir nie wieder bessere Dinge haben.
- willtemperley
Ich denke, das stimmt bis zu einem gewissen Grad, aber es hängt wirklich davon ab, wie viele Informationen das LLM zu einem Thema hat.
Sie sind erstaunlich gut in Mathe, weil Mathe seit Tag 0 Open Source ist. Sie sind aus ähnlichen Gründen großartig bei Algorithmen. C-Bindungen sind ein Kinderspiel, weil es so viel Vorarbeit gibt. Sie sind schrecklich darin, hochmoderne Funktionen in Sprachen zu verwenden, weil es noch nicht viele Daten gibt.
Ich denke, es ist ziemlich einfach vorherzusagen, worin sie auf dieser Grundlage gut sind. Ich bin mir nicht sicher, warum sie jedoch bei UI-Design so schlecht sind.
- noduerme
Als jemand, der sich mit Kryptografie nicht auskennt, weiß ich gerade genug, dass mich die Worte "eigene Kryptografie" zu Tode erschrecken.
- superjose
Ich würde sagen, es kommt darauf an.
In dem Maße, in dem sich die Software weiterentwickelt und verwendet wird.
Der Grund, warum wir Jahre damit verbracht haben, Muster zu entdecken und spezielle Syntaxen zu erstellen, war, bestimmte Domänenprobleme effizienter zu lösen und Systeme zu haben, die sich im Laufe der Zeit weiterentwickeln können.
Die einzige Konstante ist der Wandel.
Obwohl LLMs Code ausspucken (und mit großem Fachwissen beeindruckende Ausgaben liefern), muss der Entwickler das Know-how haben, um eine bestimmte Schwelle zu überschreiten.
Das Schreiben in unbekannten Sprachen mag zunächst in Ordnung erscheinen. Aber sobald man an die Grenzen geht, wird man unterwegs auf bestimmte Eigenheiten und Ineffizienzen stoßen, die das LLM umgehen kann, anstatt sie an der Wurzel zu beheben.
Zum Beispiel lerne ich seit einigen Wochen Effect.ts. Ich habe LLMs ausgiebig genutzt, aber davor gab es eine Reihe von manuellen Codierrunden.
Um Verständnis für Komponierbarkeit, die Feinheiten, wo Dinge brechen, wie, wie die Syntax gebildet wird, und wie ich einige Observability-Herausforderungen strukturieren könnte, die ich mit der Bibliothek hatte.
Wenn ich diesen Prozess nicht durchlaufen hätte, wäre die Codequalität unterdurchschnittlich gewesen. Es wäre zunächst nicht offensichtlich gewesen, aber sobald das System begann, sich weiterzuentwickeln und auf Feedback zu reagieren, wären die Dinge brüchig geworden, bestehende Kunden wären betroffen gewesen, und so weiter.
Ich bewege mich gerne schnell, ohne Dinge zu brechen
- jbstack
> Eines ist ziemlich klar: Die Handlung, sich mit einer Sprache vertraut zu machen, spielt keine Rolle mehr
Ich stimme dieser Aussage als Prämisse des Artikels überhaupt nicht zu.
Sicher, wenn es einem völlig egal ist, ob die Arbeit des Agenten zuverlässig ist oder nicht, dann muss man keine Sprache lernen. Aber wenn man ein Entwickler ist, dem seine Arbeit am Herzen liegt und der nicht nur zu 100 % Vibe-Code ausgibt, dann sollte man zumindest gut genug mit der Sprache vertraut sein, um die Ausgabe des Agenten zu überprüfen, dem Code folgen zu können und eine fundierte Entscheidung darüber zu treffen, ob man ihn übernimmt.
Interessanterweise habe ich festgestellt, dass sich meine Herangehensweise an das Sprachenlernen grundlegend geändert hat. Früher habe ich ein Buch über die eine oder zwei Sprachen studiert, die mir damals wichtig waren. Das Ziel war, kompetent zu werden. Jetzt lese ich über verschiedene Sprachen, einfach weil sie ein interessantes Paradigma demonstrieren, das mir neu ist (z.B. Haskell -> funktional, Elixir -> nebenläufig). Ich lese ein Programmierbuch wie ein fesselndes erzählendes Sachbuch: relativ schnell von vorne bis hinten, dann bin ich fertig. Das gibt mir diese "Vertrautheit", die für agentisches Codieren nützlich ist, ohne sich die Mühe zu machen, jedes obskure Syntaxdetail oder jeden Bibliotheksaufruf zu lernen. Meine Priorität ist Breite geworden (einen Überblick über viele Sprachen und Paradigmen bekommen) statt Tiefe (eine oder zwei Sprachen wirklich gut lernen).