Ladybird setzt auf Rust und beschleunigt die Umstellung mit Hilfe von KI

 (ladybird.org)
5 Punkte von GN⁺ 2026-02-24 | 1 Kommentare | Auf WhatsApp teilen
  • Das Browserprojekt Ladybird führt Rust als speichersichere Sprache ein, um C++ zu ersetzen, und nutzt KI-Tools im Migrationsprozess
  • Zuvor wurde Swift geprüft, wegen eingeschränkter C++-Interoperabilität und Plattformbeschränkungen fiel die Wahl schließlich jedoch auf Rust
  • Das erste Portierungsziel ist die JavaScript-Engine LibJS; mit Claude Code und Codex wurde per hunderten manuell gesteuerten Prompts übersetzt
  • In rund zwei Wochen wurden 25.000 Zeilen Rust-Code fertiggestellt; verifiziert wurde, dass Ausgabe und Performance vollständig mit der C++-Version übereinstimmen
  • Das Projekt will vorerst ein paralleles Entwicklungsmodell mit C++ und Rust beibehalten und langfristig Sicherheit sowie Wartbarkeit verbessern

Hintergrund zur Einführung von Rust

  • Ladybird prüfte mehrere Sprachen, um eine speichersichere Alternative zu C++ zu finden
    • Swift wurde ausgeschlossen, da die Interoperabilität mit C++ unzureichend war und die Plattformunterstützung außerhalb des Apple-Ökosystems begrenzt ist
  • Rust wurde als Sprache mit einem reifen Ökosystem für Systemprogrammierung bewertet, mit der viele Mitwirkende bereits vertraut sind
  • 2024 wurde eine Einführung noch wegen der ungeeigneten Passung von Rust zu C++-artigem OOP zurückgestellt; später fiel die Entscheidung zur erneuten Einführung aufgrund von Sicherheit und gereiftem Ökosystem
  • Mit Blick auf die bereits erfolgte Einführung von Rust in Firefox und Chromium kam das Team zu dem Schluss, dass Rust auch für Ladybird geeignet ist

Der Portierungsprozess von LibJS

  • Das erste Ziel der Umstellung ist LibJS, Ladybirds JavaScript-Engine
    • Lexer, Parser, AST, Bytecode-Generator und andere unabhängige Komponenten sowie die auf test262 basierende Testabdeckung machten sie zu einem geeigneten Ausgangspunkt
  • Für die Portierung wurden Claude Code und OpenAI Codex verwendet
    • Es handelte sich nicht um automatische Generierung, sondern um eine vom Menschen gesteuerte Übersetzung; Reihenfolge der Portierung und Codestruktur wurden direkt festgelegt
    • Mit hunderten Prompts wurden präzise Anweisungen gegeben; anschließend erfolgten Codeprüfung und Fehlersuche mit verschiedenen Modellen

Ergebnisse und Verifizierung

  • Das Ziel war, dass die C++- und Rust-Pipelines bytegenau identische Ausgaben erzeugen
  • Rund 25.000 Zeilen Rust-Code wurden in zwei Wochen fertiggestellt, wodurch eine Arbeit verkürzt wurde, die sonst mehrere Monate gedauert hätte
  • AST und Bytecode sind vollständig identisch, und in Tests sowie JS-Benchmarks gab es keinen Performanceverlust
  • Mit Lockstep-Tests, bei denen C++- und Rust-Pipeline gleichzeitig ausgeführt werden, wurde beim Surfen im Web verifiziert, ob die Ergebnisse übereinstimmen
  • Der aktuelle Code behält die aus C++ übersetzte Form bei und imitiert sogar Registerzuweisungsmuster identisch
    • Der wichtigste Grund dafür ist die Sicherstellung der Kompatibilität mit der C++-Pipeline
    • Zu einem späteren Zeitpunkt, wenn die C++-Pipeline aufgegeben wird, ist eine Vereinfachung und Bereinigung des Rust-Codes geplant

Weitere Pläne

  • Die Umstellung auf Rust wird nicht als Hauptrichtung der Projektentwicklung, sondern als parallele Arbeit vorangetrieben
  • C++- und Rust-Code werden koexistieren, bei klar definierten Interoperabilitätsgrenzen
  • Reihenfolge und Umfang der Portierung werden vom Kernteam gesteuert; externe Mitwirkende müssen sich im Voraus abstimmen
  • Langfristig wird eine schrittweise Umstellung mit dem Ziel verfolgt, Sicherheit und Wartbarkeit zu verbessern
  • Obwohl anerkannt wird, dass die Entscheidung umstritten sein kann, wird sie als richtige Wahl für Ladybirds Zukunft bewertet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-24
Hacker-News-Kommentare

  • Der klügste Teil dieses Projekts ist, dass bytegenau identische Ausgabe verlangt wurde
    Dadurch kann man die alte und die neue Pipeline parallel laufen lassen, Diffs vergleichen und beim Übersetzen entstandene Bugs sofort finden
    Viele Rewrites scheitern daran, dass Leute während des Portierens noch „Verbesserungen“ versuchen und dann Phantom-Bugs hinterherjagen, die aus Unterschieden zwischen Altversion, Neuversion oder schlicht abweichendem Verhalten entstehen
    Auch wenn die von C++ nach Rust übersetzte Version anfangs etwas unbeholfen wirkt, ist das in Ordnung. Wenn die C++-Seite später vollständig ausgemustert ist, kann man sie schrittweise idiomatischer machen

    • Ein Port ist ein guter Zeitpunkt, vieles zu verbessern, aber kein Zeitpunkt, um neue Features hinzuzufügen
      Solange die Ausgabe identisch bleibt, kann man refaktorieren, optimieren und dokumentieren
      Beim Lesen des Codes zu dokumentieren ist vermutlich der beste Zeitpunkt dafür. Bei einem populären Projekt wie Ladybird ist Dokumentation direkt ein Weg, die Entwicklungsgeschwindigkeit zu erhöhen
    • Ich hoffe, dass es mehr von dieser Art reinem Porting gibt
      Früher waren Migrationskosten so hoch, dass man es mit „wenn wir schon dabei sind, verbessern wir gleich alles“ gerechtfertigt hat, am Ende aber nur noch mehr Phantom-Bugs gejagt hat
    • Mir gefällt dieser Ansatz sehr. Vor ein paar Tagen gab es einen Beitrag aus Sicht von Tests und Verifikation, und es überrascht mich, ihn auf ein so komplexes Projekt angewandt zu sehen
    • Ich habe Web-Frameworks selbst mehrfach auf diese Weise umgestellt. Ich habe den HTTP-Ausgabe-String im neuen Code zuerst exakt angepasst und danach die alte Version vollständig gelöscht
    • Mit einer guten Testsuite funktioniert dieser Ansatz deutlich besser. Ich nehme an, dass das bei Ladybird ebenfalls so ist

  • Sie haben mit Claude Code und Codex C++-Code nach Rust übersetzt
    Nicht vollautomatisch, sondern von Menschen gesteuert und mit Hunderten kleiner Prompts feinjustiert
    Die Anforderung, dass die Ausgabe beider Pipelines bytegenau identisch sein muss, wurde von Anfang an gesetzt, und am Ende standen in zwei Wochen 25.000 Zeilen Rust-Code
    AST und Bytecode stimmten beide überein, und es wurden 0 Regressionen erreicht
    Ich denke, genau so sollte man AI für sprachübergreifendes Porting einsetzen

    • Ich habe einmal ein kaputtes Perl-Skript mit Claude nach Rust portiert
      In 80 Minuten hat es die Drupal-Struktur analysiert, das ursprüngliche Design und die Modulstruktur originalgetreu wiederhergestellt und sogar Custom-Plugins implementiert
      Inzwischen heißt es, die Site sei auf WordPress, ProcessWire, Node.js und inzwischen sogar auf Next.js umgezogen worden
    • Schade, dass AI-Unternehmen sich nicht stärker auf diese kollaborative Nutzungsform konzentrieren
      Ich will keinen „mit einem Prompt fertigen Code“, sondern Werkzeuge, mit denen ich über lange Sessions mit AI zusammenarbeite und menschliche Intelligenz verstärke (IA)
      Aber vermutlich können so etwas nur Leute mit Entwicklungswissen nutzen, weshalb der Markt klein wäre
    • Ich lerne Rust ebenfalls und habe mir bei Claude einen Skill namens „teach“ gebaut
      Claude schreibt den Code nicht selbst, sondern gibt nur Hinweise und Reviews
      Rust ist aufgrund der Spracheigenschaften schwer spontan herunterzuschreiben, und diese Arbeitsweise ist für mich sehr zufriedenstellend
    • Ich nutze Claude genauso. Nicht nach dem Muster „die AI macht alles“, sondern als Partner für Design, Review und Tests
    • Ich habe einmal ein komplexes Bash-Skript mit Claude nach golang portiert, und Geschwindigkeit wie Stabilität wurden enorm besser
      Inzwischen gibt es sogar eine wasm-Version, die im Browser läuft
      Die Krypto-Teile habe ich nicht direkt implementieren lassen, also kein Grund zur Sorge

  • Die Nachricht über den Wechsel zu Rust ist spannend, aber überraschend, weil das Ladybird-Team früher eher eine starke „Anti-Rust-Hype“-Haltung hatte
    Trotzdem dürfte es für mich viel einfacher werden, zu Ladybird beizutragen, wenn auf Rust umgestellt wird

    • Ich mag Rust auch, aber die übertriebene Begeisterung für die Sprache wirkt manchmal ermüdend
      Eine Sprache ist nur ein Werkzeug, und ich finde nicht, dass man seine Identität an eine bestimmte Sprache hängen sollte
    • Ich mag Rust nicht besonders, aber pragmatisch ist es manchmal die beste Wahl
    • Es gibt einen Link, dass Ladybird inzwischen nicht mehr C++/Swift-zentriert ist
    • Dass sich die Sprachrichtung so oft ändert, macht mich etwas unruhig. Die Kontinuität des Projekts könnte darunter leiden

  • Andreas ist ein hervorragender Ingenieur und jemand mit unternehmerischem Gespür
    Beeindruckend ist, wie er ein Hobbyprojekt zu einem industriellen Projekt weiterentwickelt hat
    Trotzdem fühlt sich so ein schneller Sprachwechsel leicht beunruhigend an

    • Andreas ist nicht einfach ein Geschäftsmann, sondern der Ingenieur, der Serenity OS über Jahre hinweg praktisch allein gebaut hat
      Ich sehe das als Ergebnis eines natürlich gewachsenen Projekts
    • Auch die Swift-Entscheidung sei eine rationale Abwägung gewesen, nachdem mehrere Sprachen direkt ausprobiert worden waren
    • Zur Einordnung: Er hat früher im Team der Apple-Safari-Engine gearbeitet
    • Trotzdem bleibt offen, ob daraus wirklich ein neuer Browser wird
    • Du sagst, es mache dich „unruhig“ — mich würde interessieren, was dich konkret beunruhigt

  • Die Aussage „unnormaler Rust-Code, den wir später aufräumen“ klingt für mich so, als deute sie auf noch einen Rewrite hin, und das macht mir Sorgen
    Wenn Startups die Sprache wechseln, wirkt das oft wie ein Warnsignal

    • Andererseits sind C++ und Rust beide Multi-Paradigmen-Sprachen, daher kann man die Struktur recht ähnlich übertragen
    • Das erinnert mich an die von Joel on Software beschriebenen „Fallstricke des Rewrites“
      Wenn Entwicklung der neuen Version und Pflege der bestehenden Features parallel laufen, entsteht ein Geschwindigkeitswettlauf, und die neue Version könnte den Anschluss verlieren
    • Aber Ladybird ist kein Startup, sondern ein offenes Projekt, deshalb hinkt der Vergleich etwas
      Linux, PHP und musl libc haben ebenfalls mehrfach vollständige Rewrites durchlaufen
    • In so einer Situation würde ich wohl einfach weiter Firefox nutzen
    • Mehrere Wochen lang mit LLMs zu portieren wirkt schon wie eine etwas seltsame Entscheidung

  • Jetzt, wo AI allgegenwärtig ist, hat sich die Rechnung für einen „kompletten Rewrite in einer neuen Sprache“ völlig verändert
    Besonders mit einer Testsuite sinkt das Risiko stark
    Wir leben in einer Zeit, in der die Bedeutung von Tests um das Zehnfache gestiegen ist

    • Ich habe in einem privaten Projekt mit AI eine Python-CLI-Bibliothek gebaut
      Mit Streamlit, Shiny, Dash und anderen UIs kann man schnell verschiedene Ansätze ausprobieren, was Prototyping sehr angenehm macht
    • Langfristig wird mit besserer AI vermutlich auch die Bedeutung von Programmiersprachen selbst abnehmen
      Schon jetzt laufen manche Projekte mit einer Kombination aus Low-Code + Agent völlig ausreichend

  • Der Teil mit „wir haben AI Code-Review machen lassen“ klingt für mich beunruhigend
    Modelle haben Grenzen dabei, logische Fehler zu erkennen

    • Wenn aber am Ende bei 65.000 Tests 0 Regressionen + identische Ausgabe herauskommen, kann man das nicht einfach ignorieren
      Entscheidend ist dann nur, ob dieses spätere „Cleanup“ auch wirklich passiert
    • Menschliche Reviewer sind ebenfalls nicht perfekt. Wenn man aus mehreren Blickwinkeln reviewt, finden sowohl AI als auch Menschen unterschiedliche Fehler
    • Das ist genau ein Bereich, den eine Testsuite absichern sollte
    • Manche wollen allerdings keinen unidiomatischen Rust-Code anfassen, der von AI erzeugt wurde
      Wenn man sich auf AI-Code stützt, entsteht leicht ein Teufelskreis wachsender AI-Abhängigkeit

  • Dass das Projekt C++ und Rust parallel entwickelt, wirkt ineffizient
    Vielleicht wäre es besser, konsequent auf eine speichersichere Sprache zu vereinheitlichen

    • Andererseits ist auch eine gemischte Codebasis wie bei Firefox gut machbar
      Solange jede Komponente nur in einer Sprache geschrieben ist, gibt es kein Problem
    • Eine vollständige Umstellung zu erzwingen kann zu großem Momentum-Verlust führen und das Projekt zum Stillstand bringen
    • Mit einer strengen Teilmenge von C++ lässt sich unter Umständen ebenfalls Speichersicherheit erreichen

  • Als 2024 Swift übernommen wurde, gab es Tweets von Andreas über Rust
    Er sagte, Rust sei großartig für kurzfristig laufende Programme, aber unbequem für langlebige Programme mit komplexen Objektgraphen
    Außerdem bewertete er die Community als toxisch
    Link zum betreffenden Tweet

    • Hat er seine Meinung geändert? Vielleicht musste C++ von Anfang an gar nicht ersetzt werden
    • Ich kann die ausgrenzende Atmosphäre der Rust-Community nachvollziehen
    • Vielleicht wurde diese AI-basierte Rust-Migration auch wegen Sponsorenanforderungen vorangetrieben

  • Ich frage mich, ob der unidiomatische Rust-Code später als technische Schuld zurückbleibt

    • Das Risiko liegt vor allem in der Aufräumphase. C++-artige Pointer-Muster können mit Rusts Ownership-Regeln kollidieren
      Das Servo-Projekt hatte ähnliche Probleme, konnte dabei aber auch latente Bugs finden
    • Nicht C++ selbst war das Problem, sondern der Wechsel zu Rust geschah wegen Speichersicherheit
    • Andreas hatte schon früher auf Probleme mit der GC-Sicherheit der JS-Runtime hingewiesen und sich eine sicherere Sprache gewünscht
      Der Wechsel zu Rust wirkt im Einklang mit dieser Philosophie wie eine reife Entscheidung