Bun (JS-Runtime) wird offenbar vibecoded von Zig nach Rust portiert

 (github.com/oven-sh)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bun-Gründer Jarred Sumner hat einen Zig-→-Rust-Portierungsleitfaden (PORTING.md) in den Branch claude/phase-a-port committet und damit ein groß angelegtes Experiment zur Sprachmigration mit Hilfe von AI-Agenten öffentlich gemacht
  • Die Portierung ist in Phase A (zunächst nur grobe Übersetzung der Logik auf Dateiebene, Kompilierung nicht erforderlich) und Phase B (Kompilierung pro Crate erfolgreich) unterteilt; dem LLM werden dabei rund 300 Mapping-Regeln für Typen und Idiome vorgegeben
  • Sumner selbst erklärte auf Hacker News, dass man sich "noch nicht für ein Rewrite entschieden habe und dieser Code mit hoher Wahrscheinlichkeit komplett verworfen wird" — derzeit also eine experimentelle Erkundungsphase
  • In der Community werden als Hintergrund unter anderem Konflikte mit der Anti-AI-Contribution-Politik von Zig nach der Anthropic-Übernahme, der Umstand, dass Bun Zig bereits geforkt betreibt, sowie Sicherheitsvorteile des Rust-Ökosystems genannt
  • Die meisten PRs werden automatisch von @robobun (AI-Bot) erzeugt und dann von CodeRabbitAI und Claude reviewt; das zeigt die praktische Machbarkeit und zugleich die Grenzen einer groß angelegten, AI-getriebenen Code-Migration

Kernstruktur des Portierungsleitfadens (PORTING.md)

  • Ziel der Portierung ist es, jeweils eine Zig-Datei in eine .rs-Datei im selben Verzeichnis umzuwandeln; in Phase A ist die möglichst originalgetreue Reproduktion der Logik das Ziel, unabhängig davon, ob der Code kompiliert
  • Die Nutzung externer asynchroner oder I/O-Crates wie tokio, rayon, hyper, async-trait, std::fs, std::net ist verboten — weil Bun seine eigene Event-Loop und seine eigenen Syscalls kontrolliert
  • async fn ist verboten; sämtliche asynchrone Verarbeitung bleibt wie in Zig beim Modell Callback + Zustandsmaschine
  • Stellen, bei denen Unsicherheit besteht, werden mit // TODO(port): markiert; performancebezogene Zig-Idiome mit // PERF(port):, um sie in Phase B zu behandeln

Regeln für Typ- und Idiom-Mapping

  • Für mehr als 50 Typ-Mappings werden Tabellen bereitgestellt, etwa []const u8 → &[u8] (niemals &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
  • defer x.deinit() wird durch Entfernen und Ersetzen via impl Drop abgebildet, errdefer durch scopeguard, comptime wird in const generics, const fn und macro_rules! übersetzt
  • Für Strings gilt konsequent bytebasierte Verarbeitung: std::string::String oder &str sind verboten, stattdessen &[u8]/Vec<u8> — weil Bun mit WTF-8 und beliebigen Bytes arbeitet
  • Für Zig-Builtins sind die Rust-Entsprechungen definiert, z. B. @intCast → T::try_from(x).unwrap() (immer prüfen), @truncate → x as T (bewusstes Wrapping), @bitCast → transmute

Crate-Map und Ownership-Modell

  • Zig-Namespaces wie @import("bun").X werden 1:1 auf rund 30 Rust-Crates wie bun_str, bun_sys, bun_jsc, bun_alloc gemappt
  • AST-/Parser-Crates behalten die bumpalo::Bump-Arena bei, andere Crates nutzen einen globalen mimalloc-Allocator, wodurch Allocator-Parameter entfallen
  • Pointer-Ownership-Mappings umfassen u. a. bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>

Reaktionen aus der Community (Lobsters · HN)

  • Viele fragen sich, ob es sich wirklich um einen Wechsel zu Rust handelt oder eher um ein Showcase für Anthropic-LLMs
  • Als möglicher Hintergrund wird ein Konflikt zwischen Zigs Anti-AI-Contribution-Politik und dem AI-zentrierten Entwicklungs-Workflow von Anthropic vermutet; zugleich wird eingeräumt, dass das auch etwas nach Verschwörungstheorie klingt
  • Es gibt Skepsis, ob ein LLM rund 300 Regeln zuverlässig befolgen kann — daneben steht die positive Einschätzung, "~16k Tokens seien für Sub-Agenten gut handhabbar"
  • Interessant ist die Beobachtung, dass der Ansatz, in Phase A zunächst nicht kompilierenden Code zu erzeugen, dem üblichen Einsatz von Coding-Agenten genau entgegengesetzt ist
  • Als mögliche Motive für den Wechsel werden außerdem der Aufwand für die Pflege von Buns Zig-Fork, Zigs häufige Breaking Changes und das Risiko genannt, ein Kernprodukt von einer noch im Beta-Stadium befindlichen Sprache abhängig zu machen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Lobste.rs-Meinungen

  • Zur Einordnung: Das ist laut dem, was Jarred Sumner dazu auf HN gesagt hat: Er arbeitet an Bun, das ist sein Branch, und dieser Thread sei eine Überreaktion auf nicht funktionierenden Code.
    Es sei noch nicht entschieden, dass es tatsächlich eine Neuschreibung geben wird, und es sei sehr gut möglich, dass dieser Code komplett verworfen wird.
    Er wolle sehen, wie eine funktionierende Version aussieht, wie die Performance ist, wie schwer es ist, die Bun-Test-Suite zu bestehen und das Ganze wartbar zu machen, und er wolle eine praktikable Rust-Version und Zig-Version direkt nebeneinander vergleichen.

    • Das erinnert mich an das Sprichwort: „Eine Lüge geht um die halbe Welt, während die Wahrheit sich noch die Schuhe anzieht.“
      Popkulturelle Tech-Interpretationen stützen sich oft vor allem auf unmittelbare Reaktionen.

  • Selbst die normalen Pull Requests bei Bun sind ziemlich chaotisch: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    Die meisten werden autonom von @robobun erstellt, per GitHub Actions auf Duplikate geprüft (auf Claude-Basis), und @coderabbitai sowie @claude reviewen sie.
    Währenddessen ist CI kaputt, und @robobun schließt am Ende Teile seiner eigenen PRs wieder, weil sie sich mit anderen von ihm erstellten PRs überschneiden.
    Merges nach main werden weiterhin von Menschen gemacht.

    • Das hätte ich nicht erwartet.
      Ich hatte Bun vor allem wegen Jarreds Performance-Besessenheit in guter Erinnerung, aber nicht damit gerechnet, dass man LLMs so im Codebase wüten lässt.

  • Das ist absurd.
    Wenn man sich das „Idiom-Mapping“ ansieht, ist es voller unsafe, und es wirkt, als würde dabei massenhaft unrustiger Code entstehen.
    Das Mapping von @fieldParentPtr("field", ptr) wirkt besonders grob.
    Allerdings scheint „Phase A“ im Grunde eine zeilenweise Übersetzung zu sein, die später per Prompt in idiomatischeres und wartbareres Rust refaktoriert werden soll.
    Das Problem ist, dass Sprachdesign die Implementierungsrichtung stark beeinflussen kann und das in der Praxis auch tut, sodass sich später schwer entwirrbare Verknotungen ergeben könnten.
    Am Ende wäre eine altmodische manuelle Neuschreibung vermutlich der bessere Weg gewesen.

    • Idiomatischen und sicheren Code könnte ein LLM vielleicht im nächsten Schritt erzeugen.
      Gerade mit der Finanzkraft von Anthropic ist das Bequeme an AI, dass sie nicht müde wird, denselben Code immer wieder zu refaktorieren.

  • Unabhängig von der Migration selbst ist die gewählte Vorgehensweise besonders interessant.
    Im verlinkten docs/PORTING.md stehen etwa 300 Portierungsregeln, und das erscheint mir zu viel, als dass ein einzelnes LLM sie alle „im Kopf behalten“ und konsequent befolgen könnte.
    Da Anthropic Bun besitzt, gibt es für diese Portierung effektiv wohl ein unbegrenztes Token-Budget, also versucht man vielleicht, mit Anzahl Dateien * Anzahl Regeln Agenten zu „garantieren“, dass alles eingehalten wird.
    Außerdem teilen sie die Portierung in zwei Stufen: A portiert jede Datei isoliert und grob, wobei erwartet wird, dass der Build kaputt ist; B verbindet alles und macht es kompilierbar.
    In Phase A sagt man den Agenten offenbar ausdrücklich, dass der Code „nicht kompilieren muss“, und lässt jede portierte Datei nach Ausgabequalität als niedrig/mittel/hoch bewerten.
    Niedrig heißt: Logik falsch; mittel heißt: Logik stimmt, aber kompiliert nicht; hoch heißt: Logik stimmt und sollte wohl kompilieren.
    Das ist fast das Gegenteil der Art, wie ich Coding-Agenten verstehe und benutze, daher bin ich auf das Ergebnis gespannt.
    Mein Gefühl ist, dass Ergebnisse sehr unvorhersehbar werden, wenn man kein klares „Endziel“ vorgibt und sagt, es müsse nicht kompilieren, und dass man in Phase B dann einen riesigen Haufen nicht vertrauenswürdigen Codes reviewen muss.
    Nach einem schnellen grep sah es so aus, als seien von 1279 solcher Qualitätsbewertungen etwa 3 % niedrig, 80 % mittel und 17 % hoch.

    • Gemessen an Mai 2026 wirken 300 Regeln völlig okay.
      PORTING.md hat etwa 16k Tokens und konzentriert sich auf die eigentliche Hauptarbeit.
      Für neue Sub-Agenten ist das nicht schlecht und vielleicht sogar ideal.

  • Ich frage mich, ob man tatsächlich auf Rust umsteigen will oder ob das eher ein Anthropic-LLM-Test ist.

    • Mein innerer Verschwörungstheoretiker sagt, das liege an Zigs jüngstem Verbot von AI-unterstützten Beiträgen und an Mattew Luggs Kritik an Buns Sprach-Fork.
      Wenn Anthropic Bun, eines der populärsten Projekte in Zig, in eine andere Sprache verschiebt, wäre das schon eine ziemlich unverhohlene Machtdemonstration.
      Ganz an diese dramatische Hypothese glaube ich zwar nicht, vielleicht will man mit Anthropics dicker Kriegskasse einfach nur das Produkt vorführen.

  • Das wirkt ziemlich interessant.
    Das Regelbündel, das jeweils auf einmal verarbeitet werden muss, scheint sich kaum ohne gigantische Code-Review-Zyklen validieren zu lassen.
    Tokens wird es genug geben, aber nach so einer Transformation dürfte es extrem schwer werden, den Code faktisch noch zu verifizieren.
    Falls Tests denselben Prozess durchlaufen müssen, frage ich mich, was am Ende überhaupt noch als Quelle der Wahrheit übrig bleibt.
    Als Experiment ist es trotzdem beeindruckend.

  • Wenn man sich anschaut, wie es den Node.js-Killern ergangen ist: Deno hat kleinere Verbesserungen wie ein Berechtigungssystem oder native TypeScript-Unterstützung gebracht, aber die Welt nicht erschüttert, und solche Funktionen wandern inzwischen auch zurück in Node.js.
    Meiner Erfahrung nach war die Developer Experience nicht wirklich besser, teils sogar schlechter wegen großartiger Tools wie pnpm.
    Es mag schneller sein, aber in meinen Anwendungsfällen habe ich in den letzten fünf bis sechs Jahren keine echten Node.js-Performanceprobleme gespürt.
    Auch JSR hat nicht die Welt verändert, stattdessen hat die Community mit npmx etwas gebaut, das inzwischen die bessere Erfahrung bietet.
    Die Standardbibliothek von Deno, etwa @std/collections, finde ich allerdings ziemlich gut und nutze sie auch.
    Bun wirkte wegen seines zu großen Umfangs von Anfang an riskant, aber ich war vorsichtig optimistisch, weil es so schien, als wolle Jarred notfalls über Jahre hinweg die beste All-in-one-JS-Runtime bauen.
    Doch seit der Übernahme durch Anthropic, Jarreds nun recht ausgeprägtem ~~Vibe-Coding~~ agentischem Entwickeln und jetzt den Nachrichten über dieses Vibe-Porting bin ich selbst bei einem experimentellen Branch überzeugt, dass das kein Projekt ist, das ich einsetzen würde.
    Deshalb dominiert Node.js weiterhin.
    Ernsthaft gesagt sind die eingebaute TypeScript-Funktionalität und SQLite schon beeindruckend.
    Ich bin nicht komplett gegen AI; kleine Python-Skripte oder Web-Apps per Vibe-Coding für sehr spezifische Probleme zu bauen, kann Spaß machen und nützlich sein.
    Aber bei komplexen Projekten mit vielen beweglichen Teilen und Nutzern verstärkt sich bei mir immer wieder die Überzeugung, dass groß angelegtes agentisches Entwickeln selbst dann, wenn es die Feature-Entwicklung kurzfristig beschleunigt, das Projekt am Ende destabilisiert und aufbläht — also ein Nettoverlust ist.
    Mir fallen da Dinge wie VSCode, Cursor, mise oder die Perplexity-Web-UI ein.
    Ist es wirklich so schwer, ein einziges JS-Dropdown zu bauen, das beim Scrollen nicht ruckelt?
    Ich hoffe, dass mehr große Tools, Bibliotheken und Projekte, von denen ich abhänge, das erkennen und strengere Anti-AI-Richtlinien einführen.

  • Das ist buchstäblich die falsche Richtung.
    Ich habe noch keinen Rust-Maintainer gesehen, der ein mittelgroßes Rust-Projekt mit Hunderttausenden Zeilen oder mehr pflegt und mit der Skalierbarkeit in einem großen Codebase zufrieden ist.

    • Freut mich.
      Ich halte Rust gerade für große Codebases für hervorragend:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      Man muss allerdings schon einigermaßen wissen, was man tut, um effizient damit arbeiten zu können:
      https://matklad.github.io/2021/09/05/Rust100k.html
      Wie Zig in diesem Kontext im Vergleich zu Rust abschneidet, weiß ich allerdings nicht so gut.
      TigerBeetle verfolgt ein ziemlich spezielles Design.
    • Als Hintergrund: Ich habe ungefähr sechs Rust-Codebases im Bereich von 10k bis 100k Zeilen gewartet, aber keine über 100k.
      Außerdem kenne ich ein paar Fälle, in denen ein Rust-Programm mit 20k Zeilen die Kernfunktionalität eines Go-Programms mit 300k Zeilen umgesetzt hat.
      Insofern erfüllt das nicht exakt die formulierten Bedingungen.
      Aber im Bereich von 10k bis 100k Zeilen bin ich als Maintainer mit Rust sehr zufrieden.
      Diese Größenordnung ist klein genug, dass ein Programm noch fokussiert bleibt, und zugleich groß genug, um eine zentrale Idee konsequent umzusetzen.
      In dieser Größe waren sowohl die Sprache als auch die Tooling-Landschaft ein großer Vorteil, jedenfalls in meiner persönlichen Erfahrung.
    • cargo-nextest hat derzeit, ohne Kommentare und Leerzeilen, 84k Zeilen Rust-Code, und als alleiniger Maintainer halte ich es nicht für möglich, das in einer anderen Sprache zu schreiben und dabei meine persönlichen Qualitätsmaßstäbe einzuhalten.

  • Vielleicht liegt es daran: https://github.com/oven-sh/bun/issues/28001

    • Ich wünschte, jemand würde erklären, wie Rust das konkret verhindert hätte.
      Das ist kein Problem der zeitlichen Speichersicherheit.