Das Bun-Rewrite in Rust ist eine beeindruckende Leistung

MMaximilian Schwarzmüller
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00BUN wurde von Zig nach Rust portiert.
00:00:02Das hast du wahrscheinlich schon gehört,
00:00:04aber da gibt es einiges aufzuarbeiten.
00:00:06Letzte Woche gab es viel Drama,
00:00:08aber es geschehen auch viele interessante Dinge.
00:00:10Und egal, ob du dich für BUN, Zig oder Rust interessierst,
00:00:14das hier ist wirklich spannend.
00:00:15Auch im Hinblick darauf, wie KI genutzt wurde
00:00:18und was das für ähnliche Projekte
00:00:20in unserer Branche allgemein bedeuten könnte.
00:00:22Nur eine kleine Randnotiz:
00:00:24Ich persönlich mag BUN ziemlich gerne.
00:00:26Es ist die JavaScript-Laufzeitumgebung, die ich
00:00:29standardmäßig für meine Projekte verwende.
00:00:30Und tatsächlich, als netter Zufall,
00:00:32habe ich letzte Woche einen neuen Kurs über BUN veröffentlicht.
00:00:35Und der funktioniert natürlich sowohl für die Rust-Version
00:00:37als auch für die Zig-Version.
00:00:39Wenn du also etwas tiefer in BUN eintauchen
00:00:41und alle Kern-APIs kennenlernen möchtest,
00:00:44denn das ist einer der größten Vorteile von BUN,
00:00:46dass so vieles direkt eingebaut ist.
00:00:48Manche mögen das nicht, ich liebe es.
00:00:50Wenn du mehr darüber erfahren willst,
00:00:51könnte der Kurs interessant für dich sein.
00:00:53Aber schauen wir uns jetzt mal genauer
00:00:54die gesamte Portierungs-Timeline an, ja?
00:00:58Das Ganze ist tatsächlich schon zwei Monate her.
00:01:01Der Blog-Beitrag erschien zwar erst letzte Woche im Juli,
00:01:04aber die Portierung selbst fand im Mai statt.
00:01:08Und sie begann Anfang Mai,
00:01:10als der “CloudFaserPort”-Branch entdeckt wurde
00:01:13im offiziellen GitHub-Repository von BUN.
00:01:15Dieser Branch enthielt eine “porting.md”-Datei,
00:01:18eine Markdown-Datei mit Anweisungen
00:01:21zur Konvertierung von Zig-Code in Rust-Code,
00:01:23wie man den Code portiert, Übersetzungstabellen
00:01:27und allgemeine Anleitungen.
00:01:28Wir kommen noch darauf zurück, wie diese Datei erstellt wurde,
00:01:30denn natürlich war KI daran beteiligt,
00:01:32wie du vielleicht schon ahnst – dazu später mehr.
00:01:34Das wurde jedenfalls entdeckt.
00:01:36Natürlich folgten daraufhin Diskussionen auf Hacker News und X.
00:01:40Es gab Leute, die begeistert waren.
00:01:43Es gab Leute, die sehr kritisch waren.
00:01:46Aber zu diesem Zeitpunkt wussten wir noch nicht viel.
00:01:47Es gibt offensichtlich eine starke Polarisierung rund um Rust.
00:01:52Es gibt Leute, die Rust lieben, so wie ich.
00:01:55Es gibt Leute, die Rust hassen.
00:01:57Es gibt Leute, die es hassen,
00:01:58dass alles in Rust neu geschrieben werden soll,
00:02:00denn man liest sehr oft,
00:02:03dass Leute verlangen, Programm XYZ solle in Rust umgeschrieben werden.
00:02:06Ich verstehe, dass das nervig ist.
00:02:08Aber natürlich gab es deshalb
00:02:09eine Menge Polarisierung.
00:02:11Aber die Portierung hatte da noch gar nicht stattgefunden.
00:02:15Das änderte sich später im Mai.
00:02:16Am 14. Mai wurde ein offizieller Pull Request eröffnet
00:02:22und dann auch zusammengeführt,
00:02:24der tatsächlich die gesamte BUN-Codebasis
00:02:28von Zig auf Rust migrierte.
00:02:30Wie du sehen kannst, ist das ein riesiger Pull Request.
00:02:32Mehr als eine Million Zeilen Code wurden hinzugefügt.
00:02:35Und das Entfernen des Zig-Codes geschah
00:02:39in einem anderen Schritt.
00:02:40Also ja, deshalb ist es kein direkter Austausch.
00:02:42Es ist eine riesige Änderung, wie man sieht,
00:02:44mit fast 7.000 Commits.
00:02:46Dieser Code wurde natürlich nicht von Menschen überprüft,
00:02:51zumindest nicht vollständig.
00:02:52Er wurde von KI geprüft.
00:02:54Es gab bestandene Tests, aber keine menschliche Überprüfung.
00:02:59Wir kommen gleich darauf zurück, wie die KI eingesetzt wurde.
00:03:02Das wurde veröffentlicht bzw. gemerged.
00:03:06Und natürlich gab es danach noch mehr Diskussionen.
00:03:08Wie ich bereits erwähnte, wurde es nicht von Menschen geprüft.
00:03:10Das ist in diesem Zeitrahmen natürlich unmöglich.
00:03:14Aber die Community stürzte sich darauf, schaute sich das an
00:03:17und analysierte Teile davon.
00:03:19Dann folgte ein weiterer, bzw. ein erster Blog-Beitrag,
00:03:23nicht der offizielle mit allen Details,
00:03:25sondern ein erstes Statement, das vom Buntine-Team
00:03:29bezüglich der Verwendung von “unsafe” veröffentlicht wurde.
00:03:32Denn eine große Kritik, die nach diesem Pull Request aufkam,
00:03:37war, dass der Rust-Code darin kein idiomatischen Rust sei.
00:03:41Es war nicht die Art von Rust-Code, die man schreiben würde oder sollte,
00:03:44wenn man dies von Grund auf neu erstellen würde.
00:03:46Stattdessen war es wirklich eher wie eine Übersetzung von Zig nach Rust.
00:03:50Und das bedeutete, dass nicht alle Rust-Best-Practices
00:03:54und Muster verwendet wurden.
00:03:55Und es gab vor allem eine beachtliche Menge
00:03:58an “unsafe”-Verwendung darin.
00:04:00Um “unsafe” zu verstehen, muss man verstehen,
00:04:03wie Rust Speicher verwaltet,
00:04:05denn das ist einer der größten Vorteile,
00:04:08und es ist ziemlich anders als in anderen Sprachen.
00:04:10Denn in den meisten Sprachen hast du entweder einen Garbage Collector,
00:04:14einen Prozess, der im Grunde erkennt,
00:04:16wenn ein Wert nirgendwo mehr im Programm verwendet wird,
00:04:19und dann den Speicher freigibt, was praktisch ist,
00:04:21aber zusätzliche Ressourcen verbraucht.
00:04:24Oder man muss es selbst erledigen.
00:04:26In Sprachen wie C zum Beispiel
00:04:28muss man den Speicher manuell zuweisen und freigeben.
00:04:31Und bei Zig ist es genauso.
00:04:33Man kann dort Speicher zuweisen, muss aber auch “free” aufrufen
00:04:37oder ihn freigeben, wenn man ihn nicht mehr benötigt.
00:04:40Man kann “defer” verwenden, was ganz nett ist.
00:04:43Das bedeutet im Grunde, dass man es aufrufen kann,
00:04:47bevor es tatsächlich ausgeführt wird.
00:04:49Es wird zurückgestellt und automatisch aufgerufen,
00:04:52sobald dieser Gültigkeitsbereich im Wesentlichen endet.
00:04:55Und das ist schön, denn es gibt verschiedene Situationen,
00:04:58in denen ein Wert möglicherweise nicht mehr benötigt wird.
00:05:00Aber dennoch, wenn man Speicher manuell bereinigen muss,
00:05:04gibt es viele Situationen,
00:05:05in denen man sich selbst ins Knie schießen kann.
00:05:07Man hat eine feinere Kontrolle,
00:05:09und das kann sehr nützlich und effizient sein,
00:05:11aber es ist auch leicht, in komplexeren Programmen
00:05:15Situationen zu vergessen,
00:05:16in denen man den Speicher dann nicht bereinigt,
00:05:19wodurch ein Speicherleck entsteht,
00:05:20oder wo man möglicherweise doppelt bereinigt,
00:05:23was ebenfalls einen Fehler verursacht.
00:05:25Und deshalb gibt es einen Kompromiss.
00:05:27Und Rust verfolgt einen anderen Ansatz.
00:05:30In Rust gibt es ein Konzept namens Ownership,
00:05:32was bedeutet, dass jeder Wert genau einen Besitzer hat
00:05:36und an den Gültigkeitsbereich gebunden ist.
00:05:38Wenn man also einen Bereich hat,
00:05:39und man kann Bereiche durch geschweifte Klammern erstellen,
00:05:41oder eine Funktion hätte auch ihren eigenen Bereich.
00:05:43Vielleicht kennen Sie dieses Konzept aus JavaScript.
00:05:46Wenn man einen Bereich hat,
00:05:47dann wird ein Wert, der darin erstellt wurde,
00:05:49von diesem Bereich besessen.
00:05:51Und wenn der Bereich endet, wird er freigegeben.
00:05:53Und das ist natürlich sehr praktisch,
00:05:55da man sich nicht um die Freigabe kümmern muss.
00:05:58Man hat auch keinen Garbage Collector.
00:06:00Stattdessen hat man diese klare Regel.
00:06:02Das kann in komplexeren Programmen zu Komplexität führen,
00:06:05wenn man Werte weitergeben muss.
00:06:07Das kann man in Rust tun,
00:06:08aber es erfordert eine andere Denkweise.
00:06:11Aber natürlich gibt es einem Speichersicherheit,
00:06:14es sei denn, man verwendet das Schlüsselwort “unsafe”.
00:06:19Wenn man das verwendet, kann man einen unsicheren Bereich erstellen.
00:06:22Und dort gelten diese Regeln nicht mehr.
00:06:24Dann ist es Ihre Aufgabe sicherzustellen,
00:06:26dass der Speicher ordnungsgemäß verwaltet wird.
00:06:28Warum sollte man das tun?
00:06:29Nun, zum Beispiel,
00:06:31wenn Sie eine C-Bibliothek einbinden,
00:06:33was in Rust möglich ist,
00:06:34können Sie sozusagen etwas C-Code beimischen,
00:06:37oder Methoden und Funktionen von C-Bibliotheken aufrufen,
00:06:40und da C von Natur aus unsicher ist,
00:06:44ist auch der Code, der auf diesen C-Code zugreift, unsicher.
00:06:48Sie benötigen also diese Funktion, um mit unserem unsicheren Code zu interagieren.
00:06:52Das wurde auch in der offiziellen Stellungnahme erwähnt,
00:06:54dass all diese unsicheren Verwendungen im Code,
00:06:56zu einem guten Teil eigentlich mit Aufrufen,
00:07:00an andere Bibliotheken, C-Bibliotheken usw. zu tun hatten,
00:07:04was sich nicht ändern wird.
00:07:07Aber sie haben auch Bereiche identifiziert,
00:07:08in denen sie den Code tatsächlich verbessern
00:07:10und “unsafe” loswerden konnten.
00:07:13Sie erwähnten, dass sie dies
00:07:14in nachfolgenden Pull Requests tun würden.
00:07:15Und das haben sie getan und tun es immer noch.
00:07:18Man kann sich diesen ersten Port also
00:07:20als Ausgangspunkt vorstellen,
00:07:22der im Laufe der Zeit verfeinert wurde.
00:07:24Es ist dennoch erwähnenswert, dass dieser erste Pull Request,
00:07:26oder dieser riesige Pull Request,
00:07:28bereits funktionierende Tests hatte.
00:07:30Es war also stabil, die Tests liefen,
00:07:32aber die Codequalität war nicht die,
00:07:35die man vielleicht erwartet hätte, wenn es in Rust
00:07:37von Grund auf geschrieben worden wäre, denn das war nicht das Ziel.
00:07:40Das war also am 21. Mai.
00:07:43Dann herrschte Stille.
00:07:45Es ist auch erwähnenswert, dass diese Version von BUN
00:07:46noch nicht veröffentlicht wurde.
00:07:49Und wenn ich das aufnehme, ist es immer noch nicht live.
00:07:50Wenn Sie BUN gerade installieren,
00:07:52erhalten Sie immer noch die SIG-Version,
00:07:54aber das sollte sich jeden Tag ändern.
00:07:56Doch dann, am 8. Juli,
00:07:58wurde der offizielle Blogbeitrag veröffentlicht,
00:07:59in dem wir viele interessante Details
00:08:02über diesen Port finden.
00:08:04Und es lohnt sich wirklich, ihn zu lesen.
00:08:06Ich verlinke ihn unten,
00:08:07denn hier gibt es viel zu lernen.
00:08:08Dieser gesamte Port, und das ist kein Geheimnis,
00:08:11wurde mit Hilfe von KI erstellt.
00:08:13wurde mithilfe von KI umgesetzt.
00:08:15Es ist erwähnenswert, dass Bun zu Anthropic gehört.
00:08:18Sie hatten also freien Zugriff auf all diese Token,
00:08:22insbesondere auch auf Claude 3.5,
00:08:24bevor es für die Öffentlichkeit freigegeben wurde.
00:08:26Diese Portierung wurde mit Claude 3.5 durchgeführt.
00:08:29Und wenn Sie jetzt Cloud Code installieren, übrigens,
00:08:32obwohl BUN 1.4, die Rust-Version, noch nicht veröffentlicht ist,
00:08:36läuft Cloud Code bereits auf Basis
00:08:39einer unveröffentlichten BUN-Version, sozusagen,
00:08:42also der Rust-Version.
00:08:44Also das dazu.
00:08:45Aber ja, dieser Port wurde mit Cloud Code erstellt
00:08:48basierend auf Claude 3.5 und natürlich mit kostenlosen Token,
00:08:52da Bun im Grunde Teil von Anthropic ist.
00:08:54Das sollte man im Hinterkopf behalten,
00:08:56denn in diesem Blogbeitrag
00:08:58lernen wir, dass, wenn man alle Token zusammenzählt,
00:09:03oder wenn man die Kosten für alle Token
00:09:04zu den üblichen API-Preisen berechnen würde,
00:09:08diese gesamte Portierung etwa 160.000 US-Dollar gekostet hätte.
00:09:13Das ist eine unglaubliche Summe, aber eigentlich,
00:09:18wenn man sich den Umfang des Projekts ansieht,
00:09:20und der Umfang umfasst 535.000 Zeilen Zig-Code bei Bun,
00:09:26wenn man diesen Umfang bedenkt
00:09:28und wie lange Menschen brauchen würden, um das nach Rust zu portieren,
00:09:32dann klingen die 160.000 US-Dollar vielleicht gar nicht so schlimm,
00:09:36je nachdem, wo man sich befindet.
00:09:38Nichtsdestotrotz ist klar, dass kein Open-Source-Projekt
00:09:43dazu in der Lage wäre.
00:09:44Und die meisten Unternehmen wären vermutlich nicht in der Lage
00:09:47oder bereit, diesen Betrag für eine Portierung auszugeben.
00:09:50Dies ist nur möglich, weil Bun Teil von Anthropic ist.
00:09:54Und natürlich ist das auch ein schöner Marketing-Stunt
00:09:58für Anthropic.
00:09:59Das war vielleicht gar nicht die Hauptabsicht.
00:10:03Das weiß ich nicht.
00:10:04Aber natürlich ist es gutes Marketing.
00:10:06Das alles sollte man im Hinterkopf behalten.
00:10:08Nichtsdestotrotz erfahren wir in diesem Blogbeitrag,
00:10:10wie Jared diese Portierung durchgeführt hat
00:10:14oder wie er dafür gesorgt hat, dass diese Portierung funktioniert.
00:10:18Und das alles begann mit dieser “porting.md”-Datei,
00:10:21die er in einem Gespräch mit Claude erstellt hat,
00:10:25in einer dreistündigen Diskussion,
00:10:26wie er im Blogbeitrag erwähnte,
00:10:28bei dem er im Grunde gemeinsam mit Claude Code
00:10:32und den Anthropic-Modellen entschied,
00:10:35wie eine solche “porting.md”-Datei aussehen muss,
00:10:37um in der Lage zu sein, Zig-Code in Rust-Code zu übersetzen.
00:10:40Nachdem er daran gearbeitet hatte und damit zufrieden war,
00:10:44testete er sie zunächst an drei Dateien.
00:10:46Und sobald er damit zufrieden war,
00:10:48ließ er Claude auf die gesamte Bun-Codebasis los.
00:10:53Nun, in diesem Blogbeitrag
00:10:54stellt er klar, dass er Claude nicht einfach nur dazu aufforderte,
00:10:57Bun in Rust neu zu schreiben – keine Fehler machen,
00:11:00sondern dass er stattdessen ein ausgeklügeltes System aufbaute,
00:11:03bei dem er einen Haupt-Agenten hatte,
00:11:07der natürlich auch Sub-Agenten startete,
00:11:09die die Portierung gemäß der “porting.md”-Datei durchführten.
00:11:13Dann hatte er zwei gegensätzliche Review-Agenten,
00:11:16die die Arbeit des Haupt-Agenten nach Fertigstellung überprüften
00:11:19und Feedback gaben,
00:11:21sowie einen Korrektur-Agenten für die Umsetzung des Feedbacks.
00:11:24Er hatte das alles in einer Schleife laufen,
00:11:25und natürlich verteilt auf mehrere Arbeitsbäume,
00:11:30um die gesamte Codebasis zu verarbeiten
00:11:33und sich durch sie hindurchzuarbeiten.
00:11:35In dem Blogbeitrag
00:11:35erwähnte er, dass er Bun in Rust neu geschrieben hat
00:11:38mithilfe von 50 dynamischen Workflows in Claude Code,
00:11:40das sind Workflows, die viele Sub-Agenten starten,
00:11:43über einen Zeitraum von 11 Tagen hinweg.
00:11:46Er hat dort auch eine schöne Grafik eingefügt.
00:11:48Überhaupt gibt es im Blogbeitrag
00:11:49schöne Grafiken,
00:11:51die es etwas leichter verständlich machen,
00:11:53und die die Anzahl der Commits zeigen, die erstellt wurden,
00:11:56und dann an verschiedenen Tagen gepusht wurden,
00:11:58sowie die Uhrzeiten.
00:12:00Das alles geschah also mithilfe von Schleifen in Claude Code,
00:12:04mithilfe vieler Sub-Agenten
00:12:05und dem klaren Prozess eines Haupt-Agenten,
00:12:08der Review-Agenten und des Korrektur-Agenten.
00:12:10Und dann verfolgte er noch einen weiteren, separaten Pfad,
00:12:15nämlich dafür zu sorgen, dass all diese Tests funktionieren.
00:12:20Das brachte seine eigenen Herausforderungen mit sich,
00:12:22denn die Testsuite ist so umfangreich und komplex,
00:12:25dass er auf verschiedene Infrastrukturbeschränkungen stieß,
00:12:29denn einige Tests verbrauchen viel Arbeitsspeicher
00:12:31und viele Tests parallel auszuführen,
00:12:33funktioniert deshalb nicht.
00:12:34Aber letztendlich hat er das auch mithilfe von KI geschafft,
00:12:39indem er die Tests ausführte, den Code korrigierte,
00:12:42die Tests erneut ausführte und so weiter.
00:12:43Es gab also viele Schleifen, viele involvierte Agenten und Sub-Agenten,
00:12:47natürlich, und eine Menge verbrauchter Token.
00:12:49165.000 Dollar an Token verbraucht.
00:12:53Ihr könnt natürlich noch tiefer einsteigen,
00:12:55und das würde ich euch auch empfehlen,
00:12:57wenn ihr an all den kleinen technischen Details interessiert seid.
00:12:59Es ist ein wirklich großartiger Blogbeitrag, der die Reise dahin dokumentiert.
00:13:03Aber das ist kurz gesagt der Weg, wie die Portierung in 11 Tagen geschah,
00:13:08mit all diesen Agenten und Sub-Agenten, verteilt auf mehrere Workflows,
00:13:1250 solcher Workflows, wie wir erfahren haben, in über 11 Tagen,
00:13:17165.000 Dollar ausgegeben für Token zu API-Preisen.
00:13:24Nun, schließlich, nachdem er im Blogbeitrag fertig war,
00:13:29erwähnte er, dass Bun 1.4 verschiedene Fehler behebt, die die letzte Zig-Version hatte,
00:13:35dass es speichereffizienter ist, dass es kleiner ist.
00:13:38Und wie wir aus der Antwort von Andrew Kelly, dem Erfinder von Zig, erfahren,
00:13:43hätten einige dieser Verbesserungen wahrscheinlich auch mit Zig erreicht werden können.
00:13:47Aber dieser Blogbeitrag ist ziemlich interessant, weil er bearbeitet wurde.
00:13:53Er ist jetzt weniger voller Wut als anfangs.
00:13:57Die erste Version war voll von persönlichen Angriffen,
00:14:00nur um dann zu sagen, dass es nicht als persönlicher Angriff gemeint war,
00:14:03aber er war voll von persönlichen Angriffen.
00:14:05Die neueste Version, die ich auch unten verlinke, ist immer noch ziemlich scharf.
00:14:11Am Ende merkt man beim Lesen der ersten Version deutlich,
00:14:14aber auch bei dieser Version,
00:14:16dass Andrew, der Erfinder von Zig, und Jared, der Erfinder von Bun,
00:14:21nicht mehr oder nicht wieder beste Freunde werden.
00:14:26Nun, er dankt Bun für die Unterstützung von Zig, auch finanziell,
00:14:31nur um dann regelrecht über diese gesamte Portierung zu toben und wie sie nicht nötig gewesen wäre,
00:14:41wenn der Bun-Code in ordentlichem Zig geschrieben worden wäre.
00:14:44Er stellt sehr deutlich klar, dass er nicht das Gefühl hat, das Bun-Repository,
00:14:48die Zig-Version, habe eine hohe Codequalität gehabt und das habe zu vielen Problemen geführt.
00:14:53Und das mag wahr sein oder auch nicht.
00:14:56Ich denke, es ist absolut möglich, dass bei einem Projekt in der Größenordnung von Bun,
00:15:01das sich mit der Geschwindigkeit bewegt, mit der sich Bun bewegt,
00:15:06die Codequalität möglicherweise nicht den Standards des Erfinders von Zig entsprach.
00:15:12Man könnte definitiv argumentieren, dass die meisten Codeprojekte
00:15:15nicht unbedingt die höchste Codequalität haben.
00:15:18Also könnt ihr euch dazu eure eigene Meinung bilden.
00:15:21Ich belasse es jetzt dabei.
00:15:24Ich finde den gesamten Antwort-Blogbeitrag ziemlich schwach,
00:15:29weil er vor Wut nur so dampft.
00:15:33Er hat einige berechtigte Punkte.
00:15:35Zum Beispiel erwähnt Jared in seinem Blogbeitrag,
00:15:40dass die Portierung von Zig zu Rust validiert wurde,
00:15:46natürlich mit all diesen Reviewer-Agenten,
00:15:48aber auch durch die Ausführung der Testsuite und deren Funktionieren.
00:15:51Und Andrew stellt korrekterweise fest, dass natürlich dieselbe Testsuite
00:15:56hätte ausreichen sollen oder nicht ausreichen sollen, um zu beweisen, dass die Zig-Version großartig ist.
00:16:00Vielleicht hätte also auch die Testsuite verbessert werden sollen.
00:16:04So oder so, diese beiden werden definitiv nicht beste Freunde.
00:16:09Und ich habe keine Meinung dazu, ob Zig oder Rust generell oder für Bun die bessere Sprache ist.
00:16:17Ich glaube jedoch, dass Rust mit seinem Speichermodell dank KI
00:16:23und der Tatsache, dass man Kompilierfehler für viele speicherbezogene Probleme erhält, ein riesiger Vorteil ist,
00:16:30vor allem im Zeitalter der KI, denn diese gesamte Portierung ist wirklich beeindruckend,
00:16:38was den Einsatz von KI angeht.
00:16:41Und sicher, es ist eine Art der KI-Nutzung, die sich die meisten von uns nicht leisten können
00:16:45oder in Unternehmen nicht leisten wollen.
00:16:48Aber es ist beeindruckend, dass das möglich war.
00:16:52Und es ist kein “Vibe Coding” oder bloßes “YOLO Prompting”.
00:16:56Hinter all dem steht ein klarer Prozess.
00:16:59Darin steckt viel Überlegung, was ich hoffentlich klargemacht habe, was definitiv auch deutlich wird,
00:17:05wenn man in die technischen Details eintaucht.
00:17:08Aber mit der ganzen Planung, der ganzen Iteration, dem Setup und der Art und Weise, wie man an die Sache herangegangen ist,
00:17:13war das eindeutig nicht nur ein einzelner Prompt, der darauf losgelassen wurde.
00:17:17Und dann werden wir sehen, was das für Möglichkeiten mit KI eröffnet.
00:17:21Und natürlich ist das Portieren einer Codebasis von einer Sprache in eine andere ein ziemlich guter Anwendungsfall für KI.
00:17:27Wenn man darüber nachdenkt: KI kann natürlich Schwierigkeiten beim Schreiben von neuem Code haben.
00:17:32Sie schreibt vielleicht nicht den Code, den man schreiben wollte, befolgt nicht die Konventionen
00:17:36oder Stile, die man befolgen wollte, und sie kann auch Dinge durcheinanderbringen.
00:17:40Nun, KI ist definitiv auch fantastisch für die Entwicklung neuer Software.
00:17:43Aber bei einer Portierung steht man vor einer anderen Art von Problemen.
00:17:47Der große Vorteil ist, dass man eine Codebasis hat, die sich die KI einfach ansehen und übersetzen kann,
00:17:53was etwas ist, das KI leisten kann, und man hat eine Testsuite.
00:17:57Es gibt also viel, worauf man aufbauen kann.
00:17:59Es ist ein guter Anwendungsfall für KI, wie es scheint, und wie diese Portierung eindeutig beweist.
00:18:04Und ich denke, das ist die interessanteste Erkenntnis hier.
00:18:08Auch, dass man Projekte in Angriff nehmen kann, die einfach unmöglich
00:18:12vorher anzugehen gewesen wären.
00:18:13Wiederum nicht für jeden, aber für bestimmte Unternehmen bestimmter Größen.
00:18:18Das könnte interessant sein.
00:18:19Die Modernisierung von Altsystemen mit Hilfe von KI kann ein großartiger Anwendungsfall sein.
00:18:26Und das zeigt und beweist, dass dies machbar ist.
00:18:30Nun, natürlich ist Bun 1.4 noch nicht draußen.
00:18:32Wir werden sehen, ob alles abstürzt und sie in einem Monat zurückrudern müssen.
00:18:36Man kann es nicht ganz ausschließen, aber ich persönlich glaube nicht, dass das passieren wird.
00:18:40Es wird bereits von einigen “Early Adoptern” in der Produktion eingesetzt, wie der Cloud Code CLI.
00:18:47Es wurde ausführlich getestet und geprüft, wenn auch natürlich von KI, nicht von menschlichen Reviewern.
00:18:54Aber ich bin ziemlich zuversichtlich, dass das funktionieren wird, und ich finde es eine beeindruckende Leistung und auch eine ziemlich beeindruckende KI-Nutzung.
00:19:03Aber wie immer interessiert es mich auch, was ihr über all das denkt.

Key Takeaway

Die vollständige Portierung von Buns 535.000 Zeilen Zig-Code auf Rust in nur 11 Tagen mittels spezialisierter KI-Agenten demonstriert, dass groß angelegte Systemmigrationen durch KI-gestützte, prozessorientierte Automatisierung realisierbar sind.

Highlights

  • Das JavaScript-Laufzeitumfeld Bun wurde innerhalb von 11 Tagen vollständig von Zig auf Rust portiert.

  • Der Portierungsprozess umfasste mehr als eine Million hinzugefügte Codezeilen und 7.000 Commits.

  • Die gesamte Portierung erfolgte mithilfe von Claude 3.5 und einer Architektur aus spezialisierten Agenten, ohne menschliche Überprüfung des Codes.

  • Die geschätzten Kosten für die bei der Portierung verbrauchten Token belaufen sich bei regulären API-Preisen auf 160.000 US-Dollar.

  • Die Rust-Version von Bun verwendet aufgrund der Herkunft des Codes aus der Zig-Basis eine signifikante Menge an “unsafe”-Codeblöcken.

  • Die Portierung nutzt 50 dynamische Workflows, die Haupt-, Review- und Korrektur-Agenten in einer kontinuierlichen Feedbackschleife einsetzen.

Timeline

Portierungs-Timeline und erste Schritte

  • Die Portierung wurde Anfang Mai eingeleitet, als ein offizieller Branch namens “CloudFaserPort” entdeckt wurde.
  • Der Prozess umfasste die Migration von einer 535.000 Zeilen umfassenden Zig-Codebasis auf Rust.
  • Die Migration erfolgte in einem umfangreichen Pull Request mit über einer Million Zeilen hinzugefügtem Code.

Die Arbeit an der Portierung begann mit einer Markdown-Anleitungsdatei, die Parameter für die Übersetzung von Zig nach Rust definierte. Der offizielle Pull Request wurde am 14. Mai gemergt, wobei der ursprüngliche Zig-Code in einem separaten Schritt entfernt wurde.

Code-Struktur und Rust-Speichersicherheit

  • Die Codequalität unterscheidet sich von idiomatischem Rust, da sie primär eine Übersetzung der Zig-Logik darstellt.
  • Aufgrund der Einbindung externer C-Bibliotheken ist ein hoher Anteil an “unsafe”-Code erforderlich.
  • Das Projekt nutzt die manuelle Speicherverwaltung von Rust-Konzepten, um Speicherfehler zu minimieren.

Kritiker bemängelten die Verwendung von “unsafe”, was jedoch notwendig ist, um die für Bun essenzielle Interaktion mit C-Bibliotheken aufrechtzuerhalten. Das Team plant, unsichere Bereiche in nachfolgenden Schritten schrittweise zu reduzieren.

KI-gestützte Migrationsarchitektur

  • Die Portierung nutzte Claude 3.5 in einer automatisierten Agenten-Struktur.
  • Ein ausgeklügeltes System aus Haupt-, Review- und Korrektur-Agenten stellte die Code-Qualität sicher.
  • Die Testsuite wurde durch wiederholte Zyklen aus KI-Ausführung und Korrektur stabilisiert.

Der Prozess basierte auf 50 dynamischen Workflows innerhalb von 11 Tagen. Die Agenten fungierten in einem geschlossenen Regelkreis, um die Portierungsvorgaben der “porting.md”-Datei strikt anzuwenden und Feedback-Schleifen zu verarbeiten.

Branchenwirkung und zukünftige Anwendungsfälle

  • Die Modernisierung von Altsystemen mittels KI ist durch diesen Fall als machbar erwiesen.
  • Die Performance von Bun 1.4 verspricht verbesserte Speichereffizienz und kompaktere Builds.
  • Die direkte Integration von Claude Code in unveröffentlichte Bun-Versionen unterstreicht die Praxistauglichkeit des Ports.

Trotz der Kontroverse zwischen den Erfindern von Zig und Bun zeigt die Portierung das Potenzial von KI bei der Übersetzung komplexer Codebasen. Die erfolgreiche Ausführung durch Early Adopter in der Produktion deutet auf die Stabilität des neuen Rust-basierten Kerns hin.

Community Posts

View all posts