Opensource browserengine Ladybird stapt deels over naar Rust voor veiligheid

De opensource browserengine Ladybird herschrijft een deel van zijn codebase met behulp van AI in Rust. Vooralsnog is het grootste gedeelte van de engine in C++ geschreven. Volgens de oprichter is Rust in sommige gevallen beter omdat het een veiligere programmeertaal is.

LadybirdIn een blogpost licht oprichter Andreas Kling toe dat er al langer gekeken werd naar een overstap van programmeertaal. Hij stelt dat de relatief jonge programmeertaal tot voor kort nog niet goed genoeg was voor object-oriented programming, een programmeerstijl waarbij elementen gebundeld worden in objecten. Inmiddels voldoet Rust volgens hem aan de eisen om voor Ladybird gebruikt te worden.

Kling gebruikte naar eigen zeggen Claude Code en Codex om delen van de engine te vertalen. Specifiek werd de JavaScript-engine, waaronder de parser, AST en bytecodegenerator van C++ naar Rust vertaald. Naar eigen zeggen kon hij met behulp van AI binnen twee weken 25.000 regels code vertalen. Er zou na het compilen geen enkel verschil in de output van de nieuwe en oude code zijn. Ook zou er geen prestatieverlies zijn.

De ontwikkelaar erkent dat zijn code eruitziet als 'vertaalde C++-code omdat het dat is', in tegenstelling tot code die native in Rust is geschreven. Later moet er een hoop code worden opgeschoond. Het is overigens niet het plan om de volledige codebase naar Rust te vertalen. Het opensourceproject blijft C++ gebruiken waar dat mogelijk is, maar gaat andere subsystemen naar Rust porten als dat een voordeel heeft.

Memory-safe programmeertaal

Rust staat bekend als een memory-safe programmeertaal. Dit verwijst naar de manier waarop de programmeertaal is opgebouwd, waarbij er fundamenteel rekening gehouden wordt met het geheugengebruik van software. Programma's in Rust zijn in principe beter beveiligd tegen het onterecht lezen van of schrijven naar het geheugen.

In 2024 vertelde Kling in een interview met Tweakers dat de keuze voor C++ oorspronkelijk niet bewust was. Hij gebruikte de volgens hem memory-unsafe-programmeertaal omdat hij er al ervaring mee had. Hij zei toen: "C++ heeft geen vangrails. Je kunt het vertellen om iets te doen wat het niet zou moeten doen en dan doet de taal dat gewoon. Modernere talen (zoals Rust, Swift en C#, red.) maken dit moeilijker."

Ladybird als tegenwicht aan Apple WebKit, Google Chromium en Mozilla Gecko

Ladybird is een opensourceproject dat voortkwam uit Klings hobbyproject SerenityOS. De browserengine moet tegenwicht bieden aan de dominantie van de drie grootste engines, Apple WebKit, Google Chromium en Mozilla Gecko. Dat zijn in de praktijk de enige massaal gebruikte browserengines.

Het doel is om in de zomer van 2026 een eerste openbare alfa te publiceren, zo vertelde Kling in een vervolginterview. Ook dan zal de engine nog niet voor iedereen zijn. "Het wordt een piece of shit. De gemiddelde gebruiker gaat de eerste versie verschrikkelijk vinden." Volgens Kling is de alfabuild bedoeld voor 'techmasochisten' en voor mensen die de browserengine puur uit technologische interesse willen testen en proberen, niet voor de gemiddelde gebruiker.

Door Yannick Spinner

Redacteur

23-02-2026 • 19:53

27

Submitter: Bedge85

Reacties (27)

Sorteer op:

Weergave:

De browser Servo is de eerste browser die in Rust geschreven is. Dit was het proefproject van Mozilla/Firefox om de browser veiliger te maken. Firefox bestaat nu voor flinke stukken uit Rust code. Ladybird gaat nu dus ook Rust gebruiken en gebruikt daarvoor AI. Het kan dus zomaar dat de AI stukken code uit Servo of Firefox ophoest voor Ladybird. Ladybird heeft een licentie met minder verplichtingen en projecten die Ladybird code gebruiken hoeven die code niet met hun gebruikers te delen. De licentie is niet copy-left, maar die van Servo en Firefox wel. De auteurs van die browsers zullen dus wel opletten of Ladybird hun werk niet steelt.
Hmm, ik heb mijn twijfels hierover aangezien het (deels) via AI word geprogrammeerd. Voornamelijk over het begrijpen van de code en de onderhoudbaarheid.
Er wordt met behulp van AI bestaande code vertaald van C++ naar Rust, niet geheel nieuwe functionaliteit in elkaar geprogrammeerd. Hoewel er soms veel te makkelijk met AI wordt omgesprongen bij programmeren, is het wel gewoon een krachtige productivity tool. Zoals ik het lees in z'n blog gaat hij er wel weloverwogen mee om:
I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.
Zelfs met het versimpelen van code (C# -> C#) heb ik het al vaak genoeg gehad dat de code niet meer compileert. En dat gaat dan om 5 regels code.
Maar waarom vraag je een AI 5 regels code te versimpelen? Ben oprecht benieuwd naar de use case. Als die 5 regels een performance bottleneck zijn kan je ze veel beter handmatig optimizeren toch?
Ben oprecht benieuwd naar de use case. Als die 5 regels een performance bottleneck zijn kan je ze veel beter handmatig optimizeren toch?
Misschien heeft @MoonRaven het over optimaliseren, maar hij schrijft versimpelen. Soms schrijf en herschrijf je een stuk code tot hij functioneel doet wat ie moet doen. Maar dat betekent niet dat het de simpelste manier is om iets te bereiken. Je heb bijvoorbeeld geneste for loops gebruikt, waar een paar mooie map, reduce en/of filter methodes het hele gedrocht in een simpel statement kan veranderen.
Nu ben ik best kritisch wat AI betreft vanwege de enorme hype maar met 5 regels code gaat het vaak gewoon in 1 keer goed hoor en anders ziet de AI het snel genoeg met dotnet build wat er mis is.

Juist met vertalen van code heb je mooie context om mee te geven aan AI. Gooi er testen bij en dan werkt het gewoon betrouwbaar.
Als je weet wat je doet, snapt wat er gedaan word en je bent geen luie vibe-coder die klakkeloos het laat toepassen, dan is er geen enkele reden tot zorg.
Tja, 25000 regels code reviewen in 2 weken lijkt me toch wel een enorme uitdaging als wilt weten wat er gedaan wordt en het niet klakkeloos accepteert.
Het gaat om vertalen he. Die code was al gereviewed.
Vertaalt of niet, de Rust code is nieuwe code en moet dus gewoon gereviewed worden. Als er voldoende tests zijn dan zal her risico lager zijn als er wat gemist wordt, zeker als er nieuwe tests zijn toegevoegd elke keer als er bugs opgelost werden, en kan je vrij rap reviewen, maar dan nog vind ik 25k regels code echt goed omzetten en reviewen best wel een uitdaging.
zeker als er nieuwe tests zijn toegevoegd elke keer als er bugs opgelost werden, en kan je vrij rap reviewen
Die tests zijn er, daarom zijn ze specifiek met deze componenten begonnen:
The lexer, parser, AST, and bytecode generator are relatively self-contained and have extensive test coverage through test262, which made them a natural starting point.
Tests zijn er echter om fouten te vinden. Reviews om te zien of het goede code is. Code die doet wat ie moet doen is niet altijd goede code. Een wijs mens heeft ooit gezegd:
Programmeren is je collega's laten zien wat je wilt dat de computer doet
Als je functioneel correcte code wilt kun je assembly code genereren en die opslaan. Er is een reden dat we broncode behouden; onderhoudbaarheid. Als je in twee weken van 25000 regels code wilt beslissen dat ze onderhoudbaar zijn dan ben je, met jouw woorden, rap bezig.
Helemaal mee eens, maar helaas leert de ervaring dat er een hele grote groep mensen zijn die denken dat je alle fouten kan vinden in code reviews en daardoor minder, of zelfs geen, tests schrijven. Vandaar dat ik het benoemde als voorwaarde om vrij rap te reviewen,je kan je dan namelijk focussen op waar een review voor bedoeld is.
Bor Coördinator Frontpage Admins / FP Powermod @TheZeroorez23 februari 2026 20:50
En die vertaalde code zal ook gereviewed moeten worden om meer zekerheid te krijgen over de veiligheid. Een vertaalslag kan ook kwetsbaarheden introduceren.
This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.
Op zijn blog (https://ladybird.org/posts/adopting-rust/) staat het bovenstaande genoemd. Hiermee klinkt het als een weloverwogen besluit om AI ter ondersteuning te gebruiken en is er goed nagedacht over de toepassing daarvan.

Het klinkt als een mooi voorbeeld van hoe je AI wel kan inzetten :). Het is natuurlijk van de zotte als je alle regels moet herschrijven met de hand, terwijl er met bewuste prompts ook stukken sneller gegenereerd kunnen worden.
Hoop dat de AI geprompt is dat het unsafe keyword verboden is, anders kan ik het ook. Dan is het gewoon een 1 op 1 vertaling, van C++ naar Rust.

Ik heb dat soort vertaalslagen eerder gezien (door mensen gedaan, met search en replace en wat eigen intelligentie) van C naar C++. of van assembly naar C. Je krijgt zinloze on onderhoudbare code die je uiteindelijk toch overnieuw moet schrijven.

Om iets naar safe Rust code te vertalen moet je soms gedeeltes her-designen, en de architectuur aanpassen.
Je krijgt zinloze on onderhoudbare code die je uiteindelijk toch overnieuw moet schrijven.
[zeurmodus]
Laten we wel zijn, dat hele Ladybird verhaal is: we vinden het niet goed dat Blink de enige relevante render engine is. We hebben geen idee waarom het Mozilla niet lukt fatsoenlijke concurrentie te bieden. We hebben geen idee waarom ze deels overgestapt zijn op Rust. We hebben geen idee. Daarom gaan wij hetzelfde proberen, maar zonder tientallen jaren ervaring en een gedegen organisatie die ons steunt.
[/zeurmodus]

Ik ben bang dat ze erg veel tijd verspillen met deze hele onderneming, en nu ook nog met deze omzetting. Ik wens ze natuurlijk alle plezier in de wereld, maar ik denk dat hun energie (en geld) beter besteed had kunnen worden.
Als iemand die kritisch is over het gebruik van AI vind ik dit nog een best een interessante toepassing. Ladybird heeft zo veel tests dat het snel opvalt als er iets niet werkt na een vertaling. De code is misschien niet even goed als het zou kunnen zijn in rust maar met een groot open source project kan dat ook leuk zijn om weer op te knappen voor rust fanatiekelingen.
Maar de (unit)tests zullen ook vertaald worden van c++ naar rust door dezelfde AI dus in hoeverre je die nog helemaal kan vertrouwen naar een AI vertaalslag is ook maar de vraag.
Ik ben geen expert van de web platform test suite maar het lijkt me dat die hetzelfde blijven draaien ongeacht welke taal je de browser in maakt.

Of begrijp ik het verkeerd?
Ik ken de codebase niet, maar normaal gesproken heb je unit tests die valideren dat functies in je codebase zich op een bepaalde manier gedragen. Je test daarbij niet alleen de standaardflow, maar ook edge cases. Wat moet een functie bijvoorbeeld doen als de input niet correct is?

Neem bijvoorbeeld een substring-functie: wat moet die doen als ze wordt aangeroepen met een negatieve offset?

Daarbovenop draai je meestal nog een aparte testlaag over het geheel van alle unit tests heen. Die voer je vaak uit met een andere tool die meer het gedrag van een eindgebruiker simuleert.
Ik ben ook programmeur ja maar ladybird heeft een unieke positie als browser.

Voor browsers bestaan web platform tests. Dat is een uniforme manier om functionaliteit over verschillende browsers te testen. Ze hadden vorige maand 1.1991.061 tests die slagen. Dat is dus een iets andere situatie dan het gemiddelde web appje met zelf gemaakte tests.
Ben wel benieuwd hoe de complexiteit, leesbaarheid en het totale aantal regels zich verhoudt tot de originele c++ code. Rust is over het algemeen makkelijker te lezen en is minder complex. In c++ kan je helemaal uit je dak gaan met templates, combineer dat met wat pre-processor magic en je hebt code die soms lastig te volgen is. Rust heeft veel meer constraints.
Komt deze browser ooit uit of kan het iets meer dan wat het nu kan? De ontwikkeling gaat heel erg langzaam, al waardeer ik wel de ontwikkeling ervan.
Er staat nog steeds "Ladybird is licensed under a 2-clause BSD license" ook al is dit dus onzin nu... Slechts een deel van de code waarop Claude getraind is is gelicenseerd als 2-clause BSD, en zelfs als alles 2-clause BSD was zouden ze van die licentie alle ontwikkelaars van alle code waarop getraind is moeten crediten, wat ze niet doen. Jammer dat dit project (en mijn respect voor Andreas Kling) op zo'n manier ten einde komt.
Als er na het compilen geen enkel verschil meer zit met C++, dan kan het dus ook onmogelijk veiliger zijn.

Om te kunnen reageren moet je ingelogd zijn