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.

In 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.

Reacties (69)

[strigi]

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.

[Lnaisd]

Hoezo zou de AI moeten stelen? het heeft alleen maar bestaande C++ code naar Rust te veranderen dus de code zelf heeft de AI al.

[novasurp]

Daarvoor wordt er door de LLM Rust-code van andere projecten gerepliceerd. Bijna elke open-source-licentie vereist hier credits van de ontwikkelaars voor, wat niet echt te doen is, want we weten niet eens waar LLM’s zoals Claude, Codex en Microsoft Copilot allemaal op getraind zijn.

[Reactie gewijzigd door novasurp op 24 februari 2026 08:57]

[bzuidgeest]

Hij repliceert niet meer dan een mens doet die leert. Jij geeft toch ook geen credits elke keer dat je een string naar de console print? Hoe je dat doet is een gegeven en het gaat maar op 1 manier (per API).

[svenslootweg]

Hij repliceert niet meer dan een mens doet die leert.

Dat is een hardnekkig misverstand dat vooral in stand gehouden wordt door AI-bedrijven om zo consequenties te ontlopen. Het is absoluut niet waar; "AI"-systemen (en dan heb ik het over generative AI zoals LLMs) worden regelmatig betrapt op het woord-voor-woord kopieren van code en teksten uit andere bronnen. En "AI"-systemen "leren" ook helemaal niet; in tegenstelling tot een mens bouwen ze geen conceptueel model op waar ze uit kunnen werken (ondanks wat AI-bedrijven beweren), maar doen ze alleen maar aan statistische reproductie van de trainingsdata.

Dus ja, wat een "AI"-systeem doet is absoluut plagiaat, maar dan met genoeg - vooral kunstmatig in stand gehouden - onduidelijkheid eromheen om het te doen voorkomen alsof dat niet zo is. De oorspronkelijke bewering dat er hoogstwaarschijnlijk Servo-code in terecht gaat komen is dus gewoon correct (ervanuitgaande dat er inderdaad "AI"-tools gebruikt worden voor het schrijven van code), want dat is hoe die systemen werken; het is de dichtstbijzijnde statistische match.

(Overigens is "stelen" niet het woord dat ik zou gebruiken, maar dat is om redenen die helemaal niets met AI te maken hebben)

[Reactie gewijzigd door svenslootweg op 24 februari 2026 14:41]

[bzuidgeest]

worden regelmatig betrapt op het woord-voor-woord kopieren van code en teksten uit andere bronne

Je weet wel, net als een mens code repliceert die ze in boeken hebben geleerd en met kleine variaties opnieuw maken. Het veranderd niets aan wat ik stel. Een AI "leert" gewoon. Het is statistiek, maar rond code ook de regels van een taal etc. Ik denk dat het jij vasthoud aan het hardnekkige misverstand dat mensen iets bijzonders in hun hoofd hebben. Maar wij zijn ook in veel opzichten niets meer dan statische reproductie van trainingsdata.... Daarom maken mensen zoveel fouten, we gokken de uitkomst aan op basis van wat we eerder hebben gezien. Iemand die harry potter heeft gelezen en gevraagd word het boek te reproduceren kan een heel erg lijkende tekst maken, vooropgesteld dat ze een beetje geheugen hebben.

AI kan ook het web op en teksten van een hoop boeken zijn daar gewoon te vinden. Niet gek dat een AI met verbatim antwoorden kan komen. Het zegt weinig over het model wat mij betreft.

[svenslootweg]

[...]

maar rond code ook de regels van een taal etc.

Nee, dat is dus precies wat het niet doet.

Overigens zijn beweringen over hoe het menselijk brein werkt weinig geloofwaardig, want dat is een heel groot onderzoeksgebied waar vooralsnog bijna alles onduidelijk is. Het enige wat we over het brein weten zijn eigenlijk de manieren waarop het niet werkt, en "statisch reproduceren van data" is er daar een van. Was het maar zo simpel.

Verder heb ik weinig zin om hierover verder te gaan, eigenlijk. Als je wilt geloven dat AI echt 'werkt' dan ga je dat toch wel geloven, de feiten zijn daarvoor niet relevant. Ik omschrijf hier hoe de techniek werkt en wat er niet klopt in je beeld, en als je reactie daarop niet is om het punt beter te proberen te begrijpen, maar om er met gestrekt been in te gaan en een manier te zoeken waarop het toch wél "echt" kan zijn, dan gaan we er hier niet uitkomen.

[bzuidgeest]

Eerlijk gezegd denk ik dat jij niet correct omschrijft hoe de techniek werkt of hoe mensen werken. Het is wel grappig dat je en zegt dat men nog veel niet weet over het menselijk brein en dan met absolute zekerheid er dingen over gaat stellen.

Laten we er inderdaad maar mee stoppen. Ik denk dat AI niet meer steelt dan een developer met een instructie boek of stackoverflow en jij mag vinden wat jij vind.

[Guru Evi]

Echter als jij de Harry Potter boeken zo goed kent dat je ze woord voor woord kunt herhalen, wilt niet zeggen dat je ‘jouw versie’ van Harry Potter mag publiceren.

Daar zit nu net het verschil tussen LLM en mensen, de LLM heeft in principe een perfect geheugen, en kan met de juiste prompts stukken tekst identiek herhalen, vooral als je maar 1 voorbeeld hebt (zoals een browser in Rust) gaat die gewoon jouw code terugspuwen omdat er maar 1 oplossing is volgens de LLM. Ik ziet dit vooral in mijn gebied (databeveiliging in de neurowetenschappen), waar bijna alle code die publiek is geschreven is door misschien 10-100 mensen, mijzelf inclusief en tussen die mensen gebruiken er maar een handjevol Python (oudere code meestal C, Java of zelfs Perl en TCL/TK). Als ik vraag om code die een bepaalde library gebruikt en schrijf mij een programma die de metadata anonimiseert krijg ik mijn eigen code die op GitHub staat bijna verbatim terug ondanks het feit dat elke andere vraag over de library gehalucineert wordt. Er wordt wel wat variatie ingezet, maar de stijl, de namen van de variabelen, zelfs hoofdlettergebruik en het feit dat de code oud is van het begin van mijn Python-conversie, dus veel globale variabelen en andere dingen die ‘veel beter’ gedaan kunnen worden moest er iemand beter meer dan een paar minuten over nadenken.

Heb net even geprobeerd en de dingen die het suggereert als verbeteringen zijn dingen die in mijn eigen README staan, zoals het gebruik van netrc om de username/password. Dan vraag ik het om een container, de Dockerfile is identiek, inclusief het (verkeerd) gebruik van version ‘3.8’ wat al een paar jaar niet meer werkt.

[Reactie gewijzigd door Guru Evi op 25 februari 2026 02:34]

[bzuidgeest]

Maar dat vind ik dus niet anders dan een mens die alleen jou github code gezien heeft en niets anders. Die zullen gewoon voor hetzelfde doel verbatim overschrijven. Ik beoordeel de AI in de context van hoe mensen zouden werken. En dan doet de AI niets vreemds. Hij kan het alleen op fenomenale schaal.

Ik heb ook gemerkt dat dingen als programmeren heel erg van de kwaliteit van de tool afhangen. Ik heb github copilot met alle premium modellen van de baas. en augment code persoonlijk met de Context Engine van hen erbij. Beide zijn gebaseerd op dezelfde modellen, maar augement code zijn context engine gooit daar nog een zo veel kwaliteit bovenop dat het niet te geloven is. Het is niet perfect, maar ik kan veel meer doen dan ooit te voren. Zelfs hex files teruglezen en equivalente code voor schrijven kunnen ze in minuten. Zie dat een mens maar doen. Reverse engineering zijn ze best goed in. Zeker als je ze een beetje begeleid. En dan reproduceren ze closed source code (ik experimenteer antieke dos games) die niemand ooit gezien heeft. En het werkt nog ook. Al halen ze alleen de timing calculatie e.d. van van alles er zo uit en file formats. Vinden ze hard code color palletes. Maar dat is wel het minste dat ze kunnen. Werkt fantastisch.

[Reactie gewijzigd door bzuidgeest op 25 februari 2026 12:01]

[Guru Evi]

Nee, dat is plagiaat. Als ik aan een programmeur vraag om iets te bouwen met een setje libraries, kijkt hij naar de documentatie en bouwt in zijn eigen stijl door te beredeneren wat op elkaar volgt. Verbatim overnemen, zonder attributie is nergens toegelaten. Als je mijn scripts wil overnemen, dien je ofwel MIT of GPLv2 te volgen

Ben je zeker dat ze de code nergens vandaan halen? Het internet is groot en diep. Reverse engineering in een clean room of na de originele code te lezen? Ghidra kan de originele code er nagenoeg identiek uithalen, valt het patroon zo dat de LLM de originele code terugvindt in zijn database, misschien gescraped van een private repo of gelekt ergens op archive.org? Waarom zijn LLM met minder parameters (informatie in de database) maar grotere context window dan zoveel slechter als ze onafhankelijk redeneren?

[Reactie gewijzigd door Guru Evi op 25 februari 2026 14:15]

[bzuidgeest]

Definieer verbatim? en dan is er ook nog een concept als "de minimis".

Ben je zeker dat ze de code nergens vandaan halen

100% Ik heb het te vaak uitgeprobeerd met enorm obscuur spul. Het is ook nog eens van voor github bestond. Als je het niet wil geloven dan geloof je het niet. Maar ik ben zeker hiervan. De resultaten zijn indrukwekkend. Ghidra levert in eerste instantie de ruwe binairy op. Via mcp bepaald de AI waar de functies zijn door te kijken naar typische call patronen e.d. Want een computer werkt nou eemaal zoals die werkt. Daarna krijg je een algemene beschrijving maar schrijven naar een vga kaart of I/O is bij ieder programma exact hetzelfde. Voor microcontrollers staan de registers en hun doel in de datasheet van de fabrikant. Een mens kan dan invullen wat er gedaan word en de AI kan dat ook maar sneller. Reverse engineering is in principe niet anders dan een vertaalslag van de ene taal in de andere.

waarom zijn LLM met minder parameters (informatie in de database) maar grotere context window dan zoveel slechter als ze onafhankelijk redeneren?

Ik snap deze opmerking net. Parameter en informatie in de database hebben geen relatie. Parameters zijn "weights" numerieke waardes. een model met meer parameters heeft typisch ook een grotere trainingset, maar de training set word niet gebundeld met de AI.

Het context windows is min of meer wat ze in hun geheugen kunnen houden. Minder parameters is typische kleinere training set. En vraag je nou werkelijk effectief waarom een mier met twee hersencellen minder kan redeneren dan een mens?

[Guru Evi]

Verbatim bedoel ik: de code zelf, de structuur, de benaming van de variabelen en hoe een programma samengesteld is (zoals het gebruik van globale variabelen). Er is geen enkele manier waar je met cleanroom reverse engineering nagenoeg identieke code terugkrijgt voor programma's van meer dan 10 lijnen.

Ik bedoelde tokens en parameters. Tokens zijn stukken data (woorden of delen van woorden), parameters zijn de gewichten hoe ze aan elkaar hangen.

Een LLM met minder parameters en/of tokens hangt intern "slechter" aan elkaar. Dus er is 'minder' data uit te halen. Een LLM met veel parameters/tokens of die toegelaten is het internet te doorzoeken, kan wel degelijk relatief goed iets kopieren omdat een zin, en zeker een stuk code niet meer is dan de woorden en hoe sterk ze aan elkaar hangen. Het verband tussen twee tokens in code ligt stukken hoger dan gewone taal, waardoor je statistich gezien altijd vb. "variabele = new Library" krijgt omdat dat een 'verplichting' van de taal is.

Die zinnen, en vooral de originele code voor code-geoptimaliseerde LLM zitten gewoon in de LLM, al dan niet gefilterd (meestal wordt commentaar eruit gefiltered tijdens training), daarnaast zie ik wel adhv de outputs dat library code (de dingen die je oa met pip install verkrijgt) voor kleinere modellen weggesmeten geworden is gedurende de training, maar wordt wel de API/docs behouden, zodat je een beschrijving kan krijgen van de library, maar in de kleinere LLM krijg je niet de "ongedocumenteerde" functies, grotere LLM zoals OpenAI, wel. Het is altijd vreemd om te zien om de publieke, maar niet-gedocumenteerde functies te zien (maar wel werken).

Een LLM is dus in mijn opinie niet meer dan lossy compression op grote stukken tekst dat in een database zit en als je de originele tekst wilt terugkrijgen, kun je dat wel degelijk doen met de juiste "prompts" (wat de query taal voor een LLM database is). Vooral als je ergens aan een edge node in de database zit, ziet de LLM niet veel andere 'opties' om het volgende stuk tekst in te vullen, waardoor je nagenoeg altijd identieke stukken tekst te zien krijgt, vaak deel van de originele training datasets. Dus als de taal dicteert dat variabele = new Library de structuur is, en jij vraagt iets over een kleine Library (laat ons zeggen PietLib) die ergens in pip staat maar door een handjevol mensen in de wereld gebruikt wordt, dan is het statistisch gezien meer waarschijnlijk dat de training data myVar = new PietLib(input=1) bevat. De LLM gaat vervolgens alle voorbeelden over PietLib met myVar = new PietLib(input=1) beginnen, wat volgt is afhankelijk van de vraag en wat meestal volgt in PietLib programma's. Als jij specifiek vraagt met een beschrijving van je eigen PietLib programma om zo'n programma uit te kramen, ga je statistisch hoogstwaarschijnlijk hele stukken van je eigen code terugzien.

Het grootste geluk van LLM is dat veel mensen altijd hetzelfde probleem oplossen in honderden manieren (zoals vroeger met DOS programma's, omdat er weinig communicatie was tussen programmeurs), waardoor het inderdaad lijkt alsof ze geen plagiaat plegen, je kunt immers kiezen uit alle soorten stijlen en de data mengen. Echter, als je echt specifiek wilt, vraag maar eens:
provide me with C code for a inverse square root implementation:

[code]#include <stdint.h>

float Q_rsqrt(float number) {
const float threehalfs = 1.5F;
...
[/code]

Gemini verandert de naam van alle variabelen, maar dezelde structuur. Sommige modellen blijken echter de variabelen te hersorteren, soms geen const, terwijl anderen meer dingen inline zetten. Maar alle versies, zien er bekend uit, echter zonder attributie ondanks dat de code GPLv2 is, zonder de bekende comments. De ChatGPT web versie zegt wel waar het vandaan komt, maar verandert de comments, Gemini web zegt gewoon "the quake method" in de uitleg, maar niets in de code over GPLv2.

Stel nu dat jij een programma aan het schrijven bent en dat klakkeloos overneemt (hoeveel mensen zijn vandaag bekend met dat lijntje geniale code), jouw programma is nu GPLv2, een 'normale' programmeur zou toch zeker:
#include <math.h> float standard_inverse_sqrt(float x) { return 1.0f / sqrtf(x); } schrijven.

[Reactie gewijzigd door Guru Evi op 25 februari 2026 21:27]

[bzuidgeest]

ik heb het gevraagd aan het goedkoopste, simpelste model dat ik heb:

Jouw input: provide me with C code for a inverse square root implementation
resultaat:

A fast inverse‑square‑root in C can be written in a few different styles depending on what you want: maximum speed, maximum accuracy, or a faithful reproduction of the Quake III trick.
The core idea is computing (1/\sqrt{x}) efficiently, often using bit‑level manipulation plus one Newton–Raphson refinement.

🚀 Fast inverse square root (Quake III–style)

This is the classic implementation using the “magic constant” 0x5f3759df:

float fast_inv_sqrt(float x) {
float xhalf = 0.5f x;
int i = (int*)&x; // reinterpret float bits as int
i = 0x5f3759df - (i >> 1); // initial guess
x = (float)&i; // reinterpret back to float
x = x (1.5f - xhalf x * x); // Newton–Raphson iteration
return x;
}


Notes

The magic constant gives a surprisingly good initial approximation.

One Newton iteration is usually enough for ~0.175% relative error.

A second iteration improves accuracy dramatically:

x = x (1.5f - xhalf x x); // 1st iteration
x = x (1.5f - xhalf x x); // 2nd iteration (optional)


⚡ Modern fast version (no undefined aliasing)

The original version uses type‑punning through pointer casts, which is undefined behavior in strict C.
A safer version uses memcpy:

#include <string.h>

float fast_inv_sqrt_safe(float x) {
float xhalf = 0.5f x;
int i;
memcpy(&i, &x, sizeof(i));
i = 0x5f3759df - (i >> 1);
memcpy(&x, &i, sizeof(x));
x = x (1.5f - xhalf x x);
return x;
}


This compiles cleanly under strict aliasing rules.

🧮 High‑accuracy version (pure Newton–Raphson)

If you don’t need the magic constant trick and want predictable accuracy:

float inv_sqrt_newton(float x) {
float y = 1.0f / x; // initial guess
// refine using Newton–Raphson for f(y) = 1/y^2 - x
for (int k = 0; k < 3; k++) {
y = y (1.5f - 0.5f x y y);
}
return y;
}


This is slower but very accurate.

🧩 Which version should you use?

GoalBest choiceWhy Maximum speed on CPUQuake‑styleVery fast, good enough for graphics/physics Strict C correctnessSafe versionAvoids aliasing UB Maximum accuracyNewton versionConverges quickly and cleanly SIMD / GPU workloadsHardware rsqrtModern CPUs/GPUs have native instructions

If you want, I can also give you:

a double‑precision version

an AVX/SSE vectorized version

a Zig/C++/Rust equivalent

or a branchless variant optimized for your target architecture

Which direction fits your project?

Het is een dom voorbeeld omdat dit soort code duidelijk onder copyright de minimis valt. Het is niet meer dan logisch dat dit altijd op elkaar lijkt. Het is wiskunde, er is maar 1 voorkeurs route, als er al meer routes zijn. Er zit niet eens echte logica of branching in. Het is niets dan een snippet en heeft niet eens copyright bescherming.

Als dit je argument is, dan sla je de plank echt mis, net als in het grootste deel van je tekst.

[Guru Evi]

Je model is redelijk duur als het al die tekst print en een chatbot, geen code agent. Een code agent zet de code in je editor zonder al de poespas.

Maar je ziet toch ook dat het gewoon dat ene algoritme in zijn database heeft, niet dat het zelf beredeneerd. En het algoritme is gelicenseerd onder GPLv2. En nee, dat is geen “normaal” algoritme, het is een specifieke implementatie die “ongeveer” werkt in specifieke omstandigheden, binnen een bepaalde band van input met een ingebouwde fout, die voor die tijd en omstandigheden aanvaardbaar waren.

Dat algoritme valt juist buiten de minimis, het gebruikt een specifieke “magic variabele” en een optimalisatiepatroon specifiek voor oude Pentiums; een implementatie van Newton’s algoritme valt binnen de minimis, het gebruik van een moderne CPU instructie, valt binnen de minimis, het gebruik van de Quake3 code is een overtreding van de GPL als je code zelf niet GPL is en vandaag zeker niet de beste oplossing, maar wel de meest bekende oplossing. En zeker als je de code in andere systemen stopt, een fout van 0.15% is goed genoeg voor pixels maar stuur er maar iets naar de maan mee en je zit snel km’s ernaast.

[Reactie gewijzigd door Guru Evi op 26 februari 2026 12:52]

[bzuidgeest]

Dat was standaard copilot. Ik heb express de goedkoopte, domste gekozen die ik heb. Niet mijn dure high end programmeer modellen.

En het algoritme is gelicenseerd onder GPLv2

Sinds wanneer is zo een enorm basis stukje wiskunde van een licentie voorzien. Belachelijk en wat mij betreft complete onzin. Het is niet functioneel, doet niets zonder werkelijk implementatie. Het is een algo dat in iedere wiskunde leerboek staat. De volgorden van de taal en code is voor de hand liggend. Als jij denkt dat dit iets voorstelt.... Ben je wel een programmeur?

Mensen hebben ook algo's in hun hoofd en nee ik zie niet dat dit "in het model" zit of zo. Net als mensen heeft het gewoon geleerd over deze constante en heeft het gewoon het kunnen googlen en aan mij presenteren net als iedere developer dat doet. Stackoverflow was de AI van de laatste 10 tot 20 jaar. Je magic variable is gewoon obvious voor iedereen die met wiskunde kan omgaan. Iedereen kan testen welke constante voor welk omgeving het beste resultaat oplevert. Gewoon rekenen.

Maar goed, zelfde model vraag aangepast naar:
provide me with C code for a inverse square root implementation. Some people worry about that the basic algorithm with the constant is to specific and licensed. Can you provide it with a different method, more general without the approximation?

Here’s a clean, license‑safe, general, and non‑approximate implementation of an inverse square root in C — no magic constants, no bit‑level hacks, and no Quake‑style algorithm.

Because you asked for “a different method, more general without the approximation”, the simplest mathematically exact way is just:

1 / sqrt(x)

This is fully portable, standards‑compliant C and uses no patented or copyright‑questionable tricks.

✅ Fully general exact inverse square root (no approximation)

#include <math.h>

#include <float.h>


/*

* Computes 1/sqrt(x) exactly using standard IEEE arithmetic.

* Returns NAN if x <= 0, matching normal floating‑point domain rules.

*/

double inverse_sqrt(double x)

{

    if (x <= 0.0) {

        return NAN;  // or handle error differently if needed

    }

    return 1.0 / sqrt(x);

}


This implementation:

Uses only standard library math, which is portable and safe.

Gives correct IEEE‑754 results, including proper handling of inf, subnormals, nan, etc.

Avoids fast‑inverse‑sqrt bit‑twiddling and thus avoids any licensing worries.

✅ If you prefer a more algorithmic (but still general & exact) method

Sometimes people want an explicit numerical method (not relying on the "1/sqrt" trick). Here are two safe alternatives:

Option 1 — Newton–Raphson for inverse sqrt directly (exact, convergent)

This is not the Quake algorithm.
This version uses a mathematically standard Newton iteration for solving:

f(y) = 1/y² − x = 0 → solves for y = 1/√x.


#include <math.h>


double inverse_sqrt_newton(double x)

{

    if (x <= 0.0)

        return NAN;


    double y = 1.0 / sqrt(x);   // good initial guess but not required

    for (int i = 0; i < 5; ++i) {

        y = y (1.5 - 0.5 x y y);

    }

    return y;

}


Notes:

This does not use any magic constants such as 0x5f3759df.

Starting at 1/sqrt(x) makes it converge in 1–2 steps, but you may start from something else if required.

Without a “copyrighted” approximation, the Newton iteration itself is just math.

Replace 5 iterations with however many are appropriate for your precision.

Option 2 — Compute sqrt via Newton’s method, then invert

If you prefer to avoid calling sqrt() entirely:


#include <math.h>


double inverse_sqrt_pure_newton(double x)

{

    if (x <= 0.0)

        return NAN;


    // Newton solve for sqrt(x)

    double s = x;

    for (int i = 0; i < 20; ++i) {

        s = 0.5 * (s + x / s);

    }

    return 1.0 / s;

}


This:

Uses only division and multiplication.

Is fully portable.

Has no constants other than small integer coefficients.

🔒 Licensing & Legal Safety

All versions above:

Use pure math, not any reverse‑engineered or patented technique.

Avoid the famous Quake III fast inverse sqrt constant.

Are not tied to any copyrighted material.

So these are safe for commercial, open‑source, or proprietary use.

Want an optimized version (SIMD, ARM NEON, AVX2, FMA)?

If you want performance beyond 1/sqrt(x) — e.g., vectorized inverse sqrt — I can provide:

AVX2 vector inverse sqrt

SSE / SSE2 version

ARM NEON version

Pure integer‑based approximate variants (not Quake’s)

Just let me know your target platform and constraints.

[Guru Evi]

Sinds wanneer is zo een enorm basis stukje wiskunde van een licentie voorzien. Belachelijk en wat mij betreft complete onzin. Het is niet functioneel, doet niets zonder werkelijk implementatie. Het is een algo dat in iedere wiskunde leerboek staat. De volgorden van de taal en code is voor de hand liggend. Als jij denkt dat dit iets voorstelt.... Ben je wel een programmeur?

Het Quake 3 algoritme is geen stukje wiskunde, het is een hack, de variabele is met de hand berekend om zo dicht als nodig en zo snel mogelijk voor de situatie een oplossing te maken. Er is een betere magic variabele dat betere resultaten geeft. Het was bedoeld om snel te lopen op Pentiums toen de sqrt() functie in C's math library (vroeger een native implementatie van Newton's algoritme) via de CPU te traag liep. Vandaag is dat opgelost met veel betere en snellere CPU-instructies.

Je verwart Newton's algoritme met het Q3 algoritme, niet hetzelfde, misschien kun je wel wat Python samenprutsen met een LLM maar je bent blijkbaar geen klassieke C programmeur vis-a-vis een computer wetenschapper. Het gebruikt 1 (of 2) stappen van Newton's algoritme om het resultaat te verfijnen.

Vraag maar aan de LLM als Quake 3 en Newton's algoritme hetzelfde zijn. Nee zegt ChatGPT en je kan de uitleg zelf wel lezen.
While you cannot copyright the abstract math or the idea of a fast inverse square root (which existed in other forms before 1999), the specific, unique code written by Id Software developers for Quake 3 is protected.

Meerdere problemen die ik dus zie, als je de LLM aan de gang laat gaan zonder al te veel kennis:
- Het feit dat het een oud algoritme neemt ondanks dat het al een paar jaren achterhaald is
- Het feit dat het steevast een algoritme neemt waar bekend is dat er een fout optreedt ondanks het feit dat moderne C/CPU een snellere (inv) sqrt heeft.
- Het feit dat het algoritme in de LLM ingebed zit, dus de claim dat het "uit zichzelf" code kan distillerent is vals
- Het feit dat die 10 lijntjes code GPL zijn en dat dit in nagenoeg alle LLMs (online en offline) zit, zelfs LLM die claimen 'veilig' te zijn voor commercieel gebruik. Dat wilt zeggen dat er dus 'andere' code ook gewoon in de LLM gebakken zit ondanks de claims dat dit niet zo is.

[Reactie gewijzigd door Guru Evi op 26 februari 2026 19:37]

[bzuidgeest]

Een ding is mij duidelijk, jij bent ook geen computer wetenschapper. Wat er eventueel ook op je visite kaartje staat.

De bak aannames klinken hoogdravend, maar je hebt wat mij betreft duidelijk geen idee van hoe de LLM werken. Zeker niet als je denkt dat een download van neem even 40 gig alle boeken, teksten, videos en zo van de wereld bevatten. Met of zonder je vage "lossy compression".

Veel plezier met je 10 lijntjes maar die regels zijn niets, niet gpl niet copyrighted, niets. Het is gewoon niet anders dan een klein beetje boeken wiskunde. Logisch dat elke developer of LLM dat kan uitspugen.

Maar goed terwijl mijn economische output hoger word en ik dus waardevoller voor mijn werkgever mag jij het op jou manier blijven doen. Maar uiteindelijk ben je een koetsier die weigert zijn paard in te ruilen voor een benzine motor. Je word vanzelf een curiositeit. LLM zijn straks gewoon niet meer weg te denken. Ze verhogen de productiviteit in specifieke use cases enorm.

En nu gaat ik verder werken aan mijn de bouw van mijn eigen programmeer taal zijn compiler.

[Reactie gewijzigd door bzuidgeest op 27 februari 2026 01:22]

[Jerie]

LLMs die het internet scrapen, doen inderdaad aan plagiaat, en komen er nog mee weg ook.

Maar niet alle ML doet dat. Je hebt ook SLMs die juist een gecontroleerde dataset hebben, en die targeted te werk gaan. Dat vind ik eigenlijk veel interessanter dan LLMs. Want LLM is alsof je met een kanonskogel op een mug schiet, waarbij deze ook nog eens op is gebouwd op allerlei zaken waar men geen controle op heeft, die men niet heeft gecontroleerd, en waar men ook geen toestemming voor heeft.

En je hebt gelijk dat het geen stelen is, maar iets anders: schending van auteursrechten / auteursrechtenschending. Quoten / fair use kun je het niet noemen.

Uiteindelijk gaan we die SLMs nauwelijks meer terugzien omdat het teveel moeite is om deze goed te trainen. Maar wat we wel gaan zien is LLMs met specifieke scopes.

[Polyprobatos]

Ik snap het punt en als de AI geprompt was om 'code te schrijven voor een open-source browser' was het risico dat hier Servo of Firefox code voor opgehoest zou worden reëel. Echter de originele Ladybird C++ code is hier al een gegeven basis.

Alles staat of valt met een goede prompt.

Je zou inderdaad nog kunnen stellen dat zelfs bij een vertaling, de door de LLM's opgedane ervaring om dit uit te voeren van Servo en Firefox afkomstig zou kunnen zijn. Dat lijkt me dan echter een auteursrechtenkwestie tussen die laatsten en de LLM. Dat zou geen weerslag moeten hebben op de uiteindelijk nog steeds vertaalde originele code in Ladybird.

Zie het zo: een Chinees bedrijf kopieert een elektrodelasapparaat van het merk Stanley en verkoopt dit onder de naam Stan Lee. Jij koopt dit lasapparaat en maakt er een fiets mee. De Stan Lee wordt uit de handel genomen. Wellicht mag/kan jij hem ook niet meer gebruiken. Maar niemand zal iets zeggen over de fiets op basis van de lasnaden.

[i-chat]

als je code uit een copy-left infected stuf software overneemt naar een licentie die vrijer is zoals een "doe maar wat je niet laten kunt licentie" dan is dat 'stelen'

wat @strigi hier oprecht opmerkt is dat makers van vergelijkbare engines (zoals gecko) die ook aan het overstappen zijn misschien 'bang zijn' dat bepaalde stukken code ge-leentje-buur't worden. het zei door de AI die het schenden van copy-left licenties niet zal begrijpen of gewoon omdat het wel heel makkelijk is om het toch maar te doen. (het zou niet voor het eerst zijn dat iemand code contribueert terwijl de licentie dat feitelijk niet toestond).


in de praktijk zal dit wel meevallen en dat is tegelijkertijd ook heel erg jammer.

Hoe eerder er een memory safe niet-mozilla of -google browser engine komt die tegelijk Free en Opensource is maar niet per se copy-left infected hoe eerder er misschien een browser komt waarin elke maker of distro-bouwer er iets 'eigens' mee kan doen zonder dat dit meteen verspreid naar alle andere versies van die browser.

kijk naar hoe mozilla's firefox nu een AI-infected junkware browser dreigt te worden die je op termijn nog liever van het balkon smijt dan bijvoorbeeld een een chromium based maar de-google'd browser zoals brave of liever nog ungoogle chromium

[bewerkers]

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.

Dit is niet waar. De maker heeft in zijn blog geschreven hoe hij het heeft aangepakt. In hele kleine stukjes heeft hij functie voor functie de code omgezet en telkens getest. En elke keer fine-tunen tot de code voldeed aan alle eisen EN een identiek gedrag vertoonde. Hij liet ook meerdere LLMs naar de code kijken voor meerdere perspectieven.
De kans dat hele blokken uit andere browsers overeenkomen is dus erg klein.

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.

[Reactie gewijzigd door bewerkers op 24 februari 2026 13:14]

[bzuidgeest]

De AI steelt niet meer dan andere programmeurs die van elkaar leren. Er zit geen verbatim code in die modellen. De AI past gewoon net als de mens die hij moet emuleren wat hij geleerd heeft toe.

De html, css en javascript specificaties staan vast. De libraries die vaak de basis voor veel dingen vormen zijn voor elke programmeur die ze gebruikt hetzelfde. Als je hetzelfde doel nastreeft is de kans op overlap in code dus groot. Code is functioneel, het is geen boek. Je kan creatief er in zijn, maar code op zich is zelden echt uniek. Het is een regelboek afhankelijk van wat de onderliggende architectuur kan. Daar veranderd AI of mens niets aan.

[MoonRaven]

Hmm, ik heb mijn twijfels hierover aangezien het (deels) via AI word geprogrammeerd. Voornamelijk over het begrijpen van de code en de onderhoudbaarheid.

[TheBigBorg]

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.

[MoonRaven]

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.

[blackSP]

Mijn ervaring is exact het tegenovergestelde. Complete refactoring een programma van mijzelf (~2500 regels, besloeg 21 files) naar een versie met beter opgezette structuur en met minimale memory footprint met Gemini maar wel strak onder mijn supervisie. Zonder problemen gecompileerd. Slechts 1 functie werkte niet naar behoren, 1 functionaliteit bleek te zijn geskipt (doordat ik zelf niet goed oplette).

[Barsonax]

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.

[codeneos]

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?

[84hannes]

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.

[jorisporis]

Daar heb ik nog weinig last van. Agents kunnen zelf compileren en checken. Heb dit zo beschreven in agent.md dat ik dat verwacht. Al doe ik geen c# maar lijkt me evident dat dit daar ook gaat. Echt crazy wat er sinds een oaar maanden kan. Al is nauwlettend overzicht wel nog nodig, soms voel ik me als iemand die producten op kwaliteit controleert aan de lopende band 😅

[bzuidgeest]

Same here, resultaat is gewoon afhankelijk van de kwaliteit van je (betaalde) model en de kwaliteit van je vraag, specificatie en je eventuele bestaande codebase zijn kwaliteit. Net als dat is als bij een junior die je helpt.

Je ben inderdaad dan een AI nanny geworden als programmeur :)

[bzuidgeest]

Misschien gebruik je gewoon een model van lage kwaliteit of heb je het doel van de code niet goed gespecificeerd. De high end betaalde modellen zijn veel beter dan wat je gratis krijgt.

Er is een simpele manier om het probleem te voorkomen. De laat de AI na zijn modificaties ook de tests draaien en dan moeten die nog steeds succesvol zijn. Een high end AI kan prima itereren. Tests draaien etc.

[TimvHelsdingen]

Coden met agents is echt mega krachtig, je moet alleen op een andere manier te werk gaan. Ik laat bijvoorbeeld de agents notities maken van de huidige staat van iedere module, and dan in agents.md refereer ik daarnaar. Er ontstaat dan automatisch een loop dat ze redelijk snel een goede context krijgen van de dingen waar ze aan werken.

Verder moet je ze echt aan kleine stukjes per keer laten werken, want een hele codebase past niet. Maar je kan dus als je een beetje weet wat je doet heel goed gewoon code laten herschrijven door agents. Wat je niet moet doen is ze eigen eigen design beslissingen laten maken over architectuur. Maar omzetten van c++ naar rust is echt een prima use van agentic coding, plus, memory leaks hoef je tenminste niet bang voor te zijn bij rust

[wooha]

… memory leaks hoef je tenminste niet bang voor te zijn bij rust

Wikipedia: Memory leak
https://www.memorysafety.org/docs/memory-safety/

Ik weet niet hoe je de smiley bedoelt, maar het voorkomen van memory leaks is geen doel van Rust. Ondersteunen van memory safety wel.

Voorkomen van memory bleeding, wat jij misschien bedoelt, is alleen een doel voorzover het een gevolg is van memory safety, zoals het voorkomen van use-after-free of out-of-bounds reads.

[himlims_]

Denk dat 50/50 is, afhankelijk van programma, features, teamverband, kennis etc

Ik ben geen programmeur, maar kan wel beetje spaghetti schrijven en wat basale zaken in elkaar draaien. Voor mij is AI als code-maatje ideaal; productiviteit aanzienlijk hoger, en functioneel aardig positief verrast


Afgelopen maand 3 tools op GitHub gepubliceerd, mede dankzij input van AI

[Oudecomputer]

Ze hebben dit resultaat wel goed getest het is niet als ubuntu en hun core utils.
Veel erger is dat rust op heel veel oude hardware en oses niet draait! Dat is waarom op oudere platvormen geen firefox meer draait.

[Tweakez]

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.

[MadEgg]

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.

[TheZeroorez]

Het gaat om vertalen he. Die code was al gereviewed.

[DdeM]

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.

[84hannes]

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.

[DdeM]

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.

[SPee]

Mijn ervaring is dat bij reviews er maar oppervlakkig naar gekeken wordt. Vaak is het gewoon "lgtm" en *approve*. Zelfs geen kritische blik of de Unit Test wel goed genoeg is.

Ik bekijk vaak de history van een project. En vrijwel altijd vindt ik wel een merge met daarin fouten in de logica, die toen niet door de reviewer is opgemerkt. Hopelijk vindt ik later daarna ook een bugfix commit, maar vaak ook niet.

[delima]

Wat een mooie quote. Van wie is die?

Ik kom al zoekend wel op deze van mijn persoonlijke held Martin Fowler:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

[Reactie gewijzigd door delima op 24 februari 2026 09:03]

[84hannes]

Ik kan de exacte quote helaas ook niet terugvinden

[Bor]

En die vertaalde code zal ook gereviewed moeten worden om meer zekerheid te krijgen over de veiligheid. Een vertaalslag kan ook kwetsbaarheden introduceren.

[Malino]

Als er na het compilen geen enkel verschil meer zit met C++, dan kan het dus ook onmogelijk veiliger zijn.

[Luminair]

Ik ga er van uit dat het niet een binaire parity heeft, maar meer op basis van het aantal web platform test dat slaagt.

[84hannes]

Ik ga er van uit dat het niet een binaire parity heeft, maar meer op basis van het aantal web platform test dat slaagt.

Het gaat niet zozeer om de gecompileerde c++/Rust code; het gaat om de JavaScript code die "gecompileerd" (uitgevoerd) wordt

I’ve done extensive testing by browsing the web in a lockstep mode where both the C++ and Rust pipelines run simultaneously, verifying that output is identical for every piece of JavaScript that flows through them.
(...)The Rust code intentionally mimics things like the C++ register allocation patterns so that the two compilers produce identical bytecode.

[Reactie gewijzigd door 84hannes op 24 februari 2026 10:38]

[84hannes]

Zelfs als dat waar is, dan kunnen ze nu de functionaliteit uitbreiden en aanpassen in Rust. De huidige geheugenproblemen verdwijnen nietz maar toekomstige kunnen grotendeels voorkomen worden.

[scramados]

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.

[codeneos]

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.

[scramados]

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?

[codeneos]

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.

[scramados]

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.

[MSalters]

Als je de browser test, is dat een systeem test. Een unit test is maar voor een klein onderdeel. Daarvoor gebruik je heel andere technologie. Een unit test roept typisch een functie of class direct aan, en is daarom typisch in dezelfde taal geschreven.

[MehHuntah]

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.

[84hannes]

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.

[Luminair]

Het geld valt volgens mij relatief mee. En verder is het ook goed voor de hele gemeenschap dat we kunnen zien hoe een nieuwe browser gebouwd wordt, waar ze tegenaan lopen, waar het juist goed in is, etc. Zo’n project heeft meer waarde dan alleen maar een nieuwe browser; hierdoor worden andere browsers (en eventueel andere web-tools zoals Node) waarschijnlijk óók beter.

[84hannes]

En verder is het ook goed voor de hele gemeenschap dat we kunnen zien hoe een nieuwe browser gebouwd wordt, waar ze tegenaan lopen, waar het juist goed in is, etc.

Daar heb je gelijk in. Ik maak me ernstige zorgen over de invloed van Google op vanalles, ook op hoe het web er uit ziet. Daarom gebruik ik Firefox. Dat er mensen zijn die denken dat het allemaal goed komt dankzij Ladybird want er is al een goed alternatief dat ze weigeren een kans te geven. Dat Ladybird als leerproject wél waarde heeft vergeet ik door deze frustratie.

[Pasteis]

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.

[codeneos]

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.

[novasurp]

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.

[MSalters]

Onzin. Ik heb geleerd van closed-source code, en toch kan ik ook open source code schrijven. Licenties zijn niet zo besmettelijk.

[YSlotboom]

Ik snap wel dat ze over willen stappen. Het feit dat Rust alle veiligheid afhandelt zorgt ook voor veel snellere development. Een deel van het werk wat je bij c++ moet doen, wordt uit handen genomen.
Nu heb ik wel vraagtekens bij het gebruik van AI. Juist omdat je bij Rust heel anders moet denken, gaat AI bij vertalen snel de mist in. In eerste instantie lijkt de code prima. Totdat je wil compilen, dan blijkt dat je overal loshangende pointers hebt wat prima mocht in c++, maar wat in Rust veel werk kost om weer recht te trekken.


Kan iemand mij vertellen wat het nut is van al die nieuwe browsers? Servo klinkt ook al wel aardig, maar heeft ook nog een lange weg te gaan.

[HollowGamer]

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.

[PaulHelper]

https://ladybird.org/#contribute de alpha zou begin 2026 moeten komen voor Linux /macOS. Je kan zelf al builden via de github