Waarom C++ nog steeds beter is dan roest in het AI-tijdperk

Invoering

Argumenten over programmeertalen worden vaak moreel theater, lang voordat ze technisch worden. De ene taal wordt omschreven als schoon, de andere als belast. De een wordt voorgesteld als de toekomst, de ander als bagage uit het verleden. Deze verhalen zijn emotioneel bevredigend omdat ze ervoor zorgen dat de geschiedenis netjes aanvoelt. Ze misleiden ook teams die systemen moeten leveren onder deadlines, budgetten, integratiebeperkingen en nu een extra kracht die tien jaar geleden niet op dezelfde manier bestond: AI-codeerassistenten en -agenten.

Zodra het genereren van code onderdeel wordt van de dagelijkse levering, verandert de vraag. Het is niet langer alleen maar 'Welke taal is elegant?' of "Welke taal is standaard veilig?" De moeilijkere en meer praktische vraag wordt deze: als een team verwacht dat AI-systemen zullen helpen bij het schrijven, refactoren, benchmarken, integreren en debuggen van productiecode, welke taal geeft deze systemen momenteel de rijkste omgeving waarin ze bruikbaar kunnen zijn? Mijn antwoord blijft C++, en de kern van het argument is noch nostalgie, noch machismo. Het is dichtheid.

C++ bevindt zich nog steeds in een dichtere wereld van publieke code, geïmplementeerde infrastructuur, tooling van leveranciers, platformvoorbeelden, optimalisatiefolklore en echte productielittekens dan Rust. AI-modellen leren van die dichtheid. Ze leren niet alleen syntaxis. Ze leren hoe mensen grote systemen aan elkaar hebben genaaid, hoe bouwbestanden zijn geëvolueerd, hoe lelijke integraties zijn gemaakt om te werken, hoe bugs op laag niveau zijn gediagnosticeerd en hoe prestatiegevoelige code eigenlijk uit woede is geschreven in plaats van uit theorie. Wanneer die modellen later worden gevraagd om te helpen bij echte engineering, is de vorm van dat historische geheugen van belang.

Dit betekent niet dat Rust zwak, niet serieus of irrelevant is. Integendeel, Rust heeft een gezonde druk uitgeoefend op de systeemprogrammering. Het maakte geheugenveiligheid onmogelijk om te negeren, verbeterde de toon van veel technische gesprekken en produceerde werkelijk krachtige tools en bibliotheken. Maar het bestaan ​​van de sterke punten van Rust doet niet automatisch de huidige voordelen van C++ op het gebied van AI-ondersteunde levering teniet. Volwassen techniek vereist vaak het vasthouden aan beide waarheden tegelijk.

Eerst bewijs, later slogans

Een zorgvuldig betoog begint met het scheiden van wat publiekelijk kan worden waargenomen en wat moet worden afgeleid. Openbare datasets die worden gebruikt in codemodelonderzoek, zoals The Stack, tonen aanzienlijk meer C++ dan Rust. Openbare enquêtes onder ontwikkelaars en GitHub-taaltrends laten nog steeds een breder absoluut gebruik van C++ in de hele industrie zien. De publieke AI-infrastructuur, van SDK's van leveranciers tot geoptimaliseerde inferentieruntimes en wiskundebibliotheken op laag niveau, legt nog steeds een wereld bloot die diep C- en C++-vormig is. Publieke benchmarking-inspanningen zoals CRUST-Bench suggereren ook dat de huidige modellen nog steeds moeite hebben om consequent veilige, idiomatische Rust te genereren in de sterke zin die Rust-gemeenschappen waarderen.

Uit deze feiten trekken we een gevolgtrekking, geen dogma. De gevolgtrekking is dat het momenteel waarschijnlijker is dat AI-systemen in veel systeemdomeinen productie-bruikbare, integreerbare en optimaliseerbare C++ genereren, omdat de omringende omgeving voor C++ rijker is. Dit is geen magie. Het is exposure gecombineerd met feedback. Een taal met meer repository's, meer build-scripts, meer hardwaregerichte voorbeelden, meer leveranciersintegraties, meer openbare bugfixes, meer prestatieonderzoeken en meer productieoorlogsverhalen biedt een model meer manieren om ongeveer gelijk te hebben voordat een menselijke ingenieur het zelfs maar begint te corrigeren.

Dit punt wordt vaak tegengesproken omdat het niet genereus klinkt tegenover het nieuwere taalgebruik. Maar het is geen belediging voor Rust om te zeggen dat het minder tijd heeft gehad om openbaar technisch sediment te verzamelen. C++ is al tientallen jaren ingebed in besturingssystemen, browsers, databases, mediastacks, beveiligingstools, game-engines, telecom, wetenschappelijk computergebruik, embedded producten en financiële systemen. Roest is snel en bewonderenswaardig gegroeid, maar groei is niet hetzelfde als geologische diepte. AI-modellen absorberen diepte.

Waarom corpusgrootte belangrijker is dan mensen toegeven

Ingenieurs behandelen de hoeveelheid trainingsgegevens soms alsof het een grof gespreksonderwerp is. In de praktijk is het op een veel menselijkere manier van belang. Een AI-agent die in een productiecodebase werkt, bedenkt meestal geen perfect algoritme op basis van de eerste principes. Het doet iets slordigers. Het kan gaan om het updaten van een CMake-bestand, het aanpassen aan een compiler-klacht op één platform, het vervangen van een hot-path container, het inpakken van een leveranciers-API, het converteren van afbeeldings- of tensor-lay-outs, het oplossen van een ABI-mismatch, of het iets minder pijnlijk maken van een oud native subsysteem zonder alles eromheen kapot te maken.

Deze taken belonen bekendheid met gewone, onvolmaakte, geleefde code. De agent heeft er baat bij dat hij niet alleen zuivere schoolvoorbeelden heeft gezien, maar ook duizenden echte pogingen heeft gezien om aangrenzende problemen op te lossen. C++ geeft modellen veel meer van dat materiaal. Er is modernere C++, meer verouderde C++ die langzaam wordt gerepareerd, meer benchmarkgestuurde C++, meer gênante C++ die op de een of andere manier nog steeds belangrijke bedrijven runt, en meer voorbeelden van mensen die precies het soort compromissen navigeren waar echte systemen om vragen.

Dit is de reden waarom "rommelige productie C++" nog steeds waardevolle trainingsgegevens is. Sommige ingenieurs horen die zin en stellen zich voor dat dit de zaak verzwakt. In werkelijkheid versterkt het het. Productiesystemen bestaan ​​niet uitsluitend uit elegante greenfield-modules. Ze omvatten verouderde interfaces, vreemde ABI-aannames, platformvoorwaarden, hardware-eigenaardigheden, gedeeltelijke migraties en code die overleefde omdat hij nuttig was voordat hij mooi werd. Als een AI-systeem veel meer voorbeelden van dat landschap in C++ heeft gezien, is het simpelweg beter voorbereid om in zo’n landschap te helpen.

Het is de moeite waard om openlijk een tegenvoorbeeld te geven. Als een team een ​​kleine greenfield-service bouwt met sterke Rust-expertise, duidelijke veiligheidseisen, bescheiden integratiebehoeften en geen zwaar inheems ecosysteem eromheen, kan Rust een betere lokale keuze zijn. In die situatie is het argument van de corpusgrootte minder doorslaggevend omdat de omringende technische context eenvoudiger is en het menselijke team het systeem binnen een smallere band van complexiteit kan houden. Het punt is niet dat C++ elk argument wint. Het punt is dat naarmate het probleem ouder, vreemder, prestatiegevoeliger en meer verstrikt raakt in de bestaande native infrastructuur, C++ steeds gemakkelijker de taal wordt waar AI-systemen effectief mee kunnen helpen.

De AI-infrastructuurwereld heeft nog steeds de vorm van C++

Zelfs als we het volume aan trainingsgegevens volledig zouden negeren, zou er nog steeds een tweede kracht zijn die de standaard richting C++ trekt: de infrastructuur onder moderne AI-producten blijft sterk native. CUDA, geoptimaliseerde wiskundebibliotheken, ONNX Runtime-internals, oneDNN, OpenVINO, tokenizer-implementaties, multimedia-voorverwerkingspijplijnen, model-serving accelerators, SDK's van hardwareleveranciers en veel implementatieruntimes zijn geschreven in C of C++ of tonen daar hun meest serieuze interfaces. Dit betekent niet dat Rust hen niet kan inschakelen. Het betekent dat het kortste pad door het landschap meestal nog steeds een C- of C++-pad is.

Dat is belangrijk omdat AI-codeermiddelen niet bruikbaar zijn in een vacuüm. Ze zijn nuttig in afhankelijkheidsgrafieken. Een model dat wordt gevraagd om te helpen bij het integreren van een runtime, het debuggen van een build, het afstemmen van een hot path of het redeneren over eigendom over de SDK-grens van een leverancier heen, heeft het voordeel als het veel aangrenzende voorbeelden in dezelfde taalfamilie heeft gezien. C++ profiteert nog steeds meer van die bekendheid met de omgeving dan Rust bij het meeste prestatiekritieke AI-infrastructuurwerk.

Dit is ook waar het gesprek over feedbackloops belangrijk wordt. Door AI gegenereerde code wordt pas echt waardevol als mensen deze snel kunnen verifiëren. C++ geeft teams vaak rijkere lokale verificatie in deze domeinen omdat het ecosysteem rond benchmarking, profilering, herhaling, sanitizers, hardwaretellers en low-level diagnostiek zo volwassen is. Wanneer een agent een wijziging in een C++-inferentiepad voorstelt, kan een team dit vaak compileren, profileren, het toewijzingsgedrag inspecteren, latentieverdelingen vergelijken en snel itereren. Rust heeft absoluut ook sterke tools, maar in veel AI-aangrenzende native systemen maakt de gecombineerde dichtheid van bibliotheken, voorbeelden, profilers en bestaande praktijken C++ nog steeds de gemakkelijkere plek om strakke human-in-the-loop-correctielussen uit te voeren.

Waarom teams vaak sneller werken met C++, zelfs als roest er schoner uitziet

Dit is het punt dat de ideologie neigt te beledigen, omdat het onbeleefd klinkt in de zin van reinheid. Roest ziet er vaak schoner uit op het whiteboard. Eigendom is expliciet. De compiler bewaakt belangrijke fouten. De cultuur rond correctheid is bewonderenswaardig. Maar productiesnelheid is niet identiek aan taalelegantie. De werkelijke leveringssnelheid komt voort uit de hele cyclus: bestaande codebase, beschikbare bibliotheken, talentenpool, debugging-tools, implementatiebeperkingen, kwaliteit van de AI-ondersteuning en de kosten van nog een wijziging volgende maand.

C++ wint momenteel die bredere lus in veel systemen uit het AI-tijdperk, omdat teams meer van de omringende wereld kunnen vragen zonder de taal te verlaten. Ze kunnen oude native bibliotheken integreren, profilers toevoegen die zijn gebouwd met native prestatiewerk in gedachten, allocators afstemmen, platformspecifieke faciliteiten exploiteren en putten uit een veel grotere hoeveelheid openbare voorbeelden als er iets misgaat. AI-assistenten profiteren van precies dezelfde realiteit. Wanneer de wereld rondom het model dicht en goed bereisd is, verbeteren de ruwe ontwerpen van het model sneller.

Stel je voor dat twee teams een latentiegevoelige inferentieservice bouwen met wat aangepaste voorverwerking, een ingewikkelde implementatiematrix en de behoefte aan herhaalde afstemming van de prestaties. Het Rust-team kan een kleinere reeks geheugenveiligheidsbugs produceren, en dat is niet triviaal. Maar als het C++-team het ecosysteem directer kan integreren, sterkere AI-suggesties kan krijgen in de daadwerkelijke codebase die ze hebben, en prestatieveranderingen sneller kan verifiëren met volwassen native tooling, kan het algehele resultaat nog steeds in het voordeel van C++ zijn. In zakelijke termen is dat belangrijker dan de vraag of één taal online een filosofisch betoog heeft gewonnen.

Een nuttig tegenvoorbeeld houdt ons eerlijk. Als het dominante risico in een project niet integratie of prestatie-evolutie is, maar geheugenveiligheid in een nieuwe dienst met relatief eenvoudige afhankelijkheden, kan Rust absoluut betere organisatorische resultaten creëren. De fout is om die waarheid te nemen en deze zonder onderscheid te exporteren naar elk AI-aangrenzend systeemprobleem. Talen winnen in contexten, niet in preken.

Wat roest nog steeds goed doet

Rust verdient respect, en het argument voor C++ is zwakker als het een karikatuur is van Rust. Roest is uitstekend in het zichtbaar maken van onveilige aannames. Het creëert een sterke discipline rond eigendom en levens. Het is vaak een overtuigende keuze voor een greenfield-infrastructuur waarbij correctheid en onderhoudbaarheid domineren boven compatibiliteit met een bestaande inheemse wereld. In sommige teams verbetert Rust ook de duidelijkheid over de werving, omdat de codebase zelf een bepaald soort technische ernst afdwingt.

Het is ook belangrijk om duidelijk te zeggen dat C++ niet standaard wint, alleen maar omdat het ouder is. Ongedisciplineerd C++ blijft gevaarlijk. Als een team een ​​zwakke beoordelingscultuur heeft, geen profileringsgewoonte, slechte tests en geen respect voor waarneembaarheid, dan zullen grotere corpora en rijkere tools het niet redden. AI-systemen kunnen die chaos net zo gemakkelijk vergroten als ze goede engineering kunnen versnellen. De echte claim is beperkter en praktischer: gegeven gedisciplineerde teams die prestatiegevoelige, integratiezware systeemproblemen uit het AI-tijdperk oplossen, is C++ vandaag de dag nog steeds de sterkste standaardinzet omdat agenten, tools en de zwaartekracht van het ecosysteem dit allemaal versterken.

Dit is de reden waarom ik de voorkeur geef aan de zinsnede standaardinzet in plaats van universele winnaar. Een standaardweddenschap is wat u kiest als de bewijslast nog niet naar elders is verschoven. Rust kan die verschuiving in specifieke projecten verdienen. Maar C++ begint nog steeds met meer bewijs in zijn voordeel wanneer het werk diep verweven is met de native AI-infrastructuur, prestaties op laag niveau, langlevende productiesystemen of het soort codebase dat AI-agenten in grote publieke hoeveelheden hebben gezien.

Een praktische manier om te beslissen

Als het hot path native is, de afhankelijkheidsgrafiek native is, het profileringsverhaal ertoe doet, en je verwacht dat AI-assistenten helpen bij rommelige echte productiecode, dan verdient C++ het om je eerste serieuze taaldiscussie te zijn. Als het systeem greenfield is, de veiligheidssituatie domineert, het omliggende ecosysteem al de vorm van roest heeft en het probleem niet sterk afhankelijk is van oude inheemse lagen, wordt roest aantrekkelijker. Als het systeem beide werelden bevat, wat velen doen, is het volwassen antwoord vaak hybride architectuur in plaats van tribale zuiverheid.

Dit raamwerk kalmeert het gesprek omdat het de beslissing om te werken teruggeeft in plaats van identiteit. Een native inference runtime binnen een bestaand C++-platform is niet hetzelfde probleem als een nieuwe control-plane-service. Een mediapijplijn met lage latentie is niet hetzelfde probleem als een backend-API. Een model-serving edge-component is niet hetzelfde probleem als een keten-native state-transition engine. Zodra we het eigenlijke werk een naam geven, ziet de taalkeuze er doorgaans minder ideologisch en meer voor de hand liggend uit.

Er zit ook een menselijk voordeel aan het op deze manier nemen van de beslissing. Teams worden coöperatiever als ze niet langer vragen welke taal bewondering verdient, maar beginnen te vragen welke taal het huidige systeem de beste kans geeft om betrouwbaar, begrijpelijk en voor verbetering vatbaar te worden. AI-assistentie maakt dit nog belangrijker. Agenten zijn krachtig als ze zijn ingebed in een cultuur van verificatie, niet als ze worden gebruikt om taalfandom met synthetisch vertrouwen te versieren.

De echte kans

De diepere kans in het AI-tijdperk is niet alleen dat agenten code kunnen schrijven. Het is dat ze nu kunnen deelnemen aan de hele feedbacklus rond volwassen systemen: het lezen van oude code, het voorstellen van bewerkingen, het verbeteren van benchmarks, het naar boven halen van profiler-aanwijzingen, het vertalen van ruwe ideeën in compileerbare experimenten en het helpen van ingenieurs om sneller dan voorheen van vermoeden naar meten te gaan. In die wereld is de taal die er het meeste baat bij heeft niet noodzakelijkerwijs degene met het mooiste theoretische verhaal. Het is degene met het dikste web van publieke, praktische, beproefde realiteit.

Tegenwoordig is die taal voor een grote groep ernstige systeemproblemen nog steeds C++. En dat is goed nieuws, niet omdat de industrie moet stoppen met leren van Rust, maar omdat teams de enorme hoeveelheid bestaande inheemse kennis kunnen gebruiken in plaats van te doen alsof deze verdween op het moment dat AI arriveerde. De meest productieve houding is niet triomfalisme. Het is dankbaarheid. C++ heeft decennia aan echt technisch geheugen verzameld, en AI-systemen maken dat geheugen nu gemakkelijker te gebruiken. Verstandige teams zullen hiervan profiteren.

Hands-On Lab: bouw en verbeter een native scoringspijplijn

Als een artikel over de taalkeuze in het AI-tijdperk geen code bevat, dreigt het een preek te worden.

Laten we dus een klein native C++-hulpprogramma bouwen, van het soort dat AI-agenten in echte bedrijven voortdurend moeten verbeteren: een pijplijn voor het scoren van tekst die gegevens laadt, eenvoudige functies berekent, de resultaten sorteert en de bovenste rijen afdrukt.

Het is met opzet bescheiden. De meeste productie-engineering is bescheiden.

main.cpp

#include <algorithm>
#include <chrono>
#include <cctype>
#include <fstream>
#include <iostream>
#include <string>
#include <string_view>
#include <vector>

struct Sample {
    std::string text;
    double score = 0.0;
};

static int count_digits(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::isdigit(c) ? 1 : 0;
    }
    return n;
}

static int count_upper(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::isupper(c) ? 1 : 0;
    }
    return n;
}

static int count_punct(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::ispunct(c) ? 1 : 0;
    }
    return n;
}

static double score_line(std::string_view s) {
    const auto len = static_cast<double>(s.size());
    const auto digits = static_cast<double>(count_digits(s));
    const auto upper = static_cast<double>(count_upper(s));
    const auto punct = static_cast<double>(count_punct(s));
    return len * 0.03 + digits * 0.7 + upper * 0.15 - punct * 0.05;
}

int main(int argc, char** argv) {
    if (argc < 2) {
        std::cerr << "usage: scorer <input-file>\n";
        return 1;
    }

    std::ifstream in(argv[1]);
    if (!in) {
        std::cerr << "cannot open input file\n";
        return 1;
    }

    std::vector<Sample> rows;
    rows.reserve(200000);

    std::string line;
    while (std::getline(in, line)) {
        rows.push_back({line, 0.0});
    }

    const auto t0 = std::chrono::steady_clock::now();
    for (auto& row : rows) {
        row.score = score_line(row.text);
    }
    std::sort(rows.begin(), rows.end(), [](const Sample& a, const Sample& b) {
        return a.score > b.score;
    });
    const auto t1 = std::chrono::steady_clock::now();

    const auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(t1 - t0).count();
    std::cout << "processed " << rows.size() << " rows in " << ms << " ms\n";

    const size_t limit = std::min<size_t>(5, rows.size());
    for (size_t i = 0; i < limit; ++i) {
        std::cout << rows[i].score << " | " << rows[i].text << "\n";
    }
}

Bouwen

Op Linux of macOS:

g++ -O2 -std=c++20 -o scorer main.cpp
./scorer sample.txt

Op Windows met MSVC:

cl /O2 /std:c++20 main.cpp
.\main.exe sample.txt

Waarom dit kleine programma nuttig is

Omdat het precies het soort code is waarin AI-ondersteunde engineering tastbaar wordt:

• het is inheems
• het raakt snaren en geheugen
• het heeft een meetbare looptijd
• het kan worden geprofileerd
• het kan stapsgewijs worden verbeterd

Dat is tegenwoordig de echte habitat van veel C++-agents: geen grote demonstraties, maar gewone native programma's die beter moeten worden zonder opnieuw uitgevonden te worden.

Testtaken voor liefhebbers

Als je van het artikel een praktische oefening wilt maken, probeer dan deze:

1. Vraag uw favoriete codeeragent om het programma te optimaliseren zonder de uitvoer te wijzigen. Controleer of het dubbele passen of onnodige tijdelijke contracten vermindert.
2. Voeg afzonderlijke timing toe voor het laden, scoren en sorteren van bestanden. Controleer waar de tijd werkelijk naartoe gaat.
3. Vervang de invoer door een miljoen regels en vergelijk de kwaliteit van de optimalisaties die door verschillende agenten worden voorgesteld.
4. Port het hulpprogramma naar Rust en vergelijk de ervaring eerlijk: wat voelde duidelijker, wat voelde zwaarder, en welke omringende gereedschappen volwassener aanvoelden voor deze exacte taak.
5. Voer de C++-versie uit onder een profiler en noteer of uw eerste gok over de hotspot daadwerkelijk juist was.

Dit is een kleine oefening, maar juist daarom nuttig. De meeste technische debatten worden waarheidsgetrouwer als ze gedwongen worden het contact met een klein, echt programma te overleven.

Samenvatting

Roest verdient het respect dat het krijgt. Het verhoogde de standaard voor veiligheidsgesprekken en gaf systeemprogrammering een gezondere reeks standaardinstellingen. Maar het AI-tijdperk beloont niet alleen wanbetalingen. Het beloont de taal die centraal staat in het grootste levende corpus van echte code, het diepste ecosysteem van integraties op laag niveau, de rijkste optimalisatiecultuur en de snelste praktische lus van gegenereerd concept naar meetbaar productieresultaat. Tegenwoordig beschrijft dat C++ nog steeds sterker dan Rust.

Dat maakt C++ niet moreel superieur, en het maakt Rust niet irrelevant. Het betekent eenvoudigweg dat AI-agenten voor veel ernstige systeemproblemen nog steeds meer bruikbare grond onder hun voeten hebben als de doelwereld C++ is. Teams die dit begrijpen, kunnen betere beslissingen nemen zonder drama. Ze kunnen van Rust leren waar Rust het sterkst is, en toch het immense geaccumuleerde geheugen van C++ gebruiken waar dat geheugen economisch het meest waardevol is.

Referenties

1. GitHub oktober 2024: https://github.blog/news-insights/octoverse/octoverse-2024/
2. GitHub oktober 2025: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
3. Stack Overflow-ontwikkelaarsenquête 2023: https://survey.stackoverflow.co/2023
4. Stack Overflow Developer Survey 2025 Technologiesectie: https://survey.stackoverflow.co/2025/technology/
5. De Stack-datasetkaart: https://huggingface.co/datasets/bigcode/the-stack
6. Het stapelpapier: https://arxiv.org/abs/2211.15533
7. ICLR 2025-paper over de impact van codegegevens in pre-training: https://openreview.net/pdf?id=zSfeN1uAcx
8. CRUST-Bench: een uitgebreide benchmark voor C-to-safe-roesttranspilatie: https://arxiv.org/abs/2504.15254
9. CUDA C++ Programmeerhandleiding: https://docs.nvidia.com/cuda/cuda-c-programming-guide/
10. ONNX Runtime C/C++ API: https://onnxruntime.ai/docs/api/c/index.html
11. PyTorch C++ frontend-documentatie: https://docs.pytorch.org/cppdocs/frontend.html
12. C++ Kernrichtlijnen: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines