Warum C++ Rust im KI-Zeitalter immer noch schlägt

Einführung

Auseinandersetzungen über Programmiersprachen werden oft zu moralischem Theater, lange bevor sie zum Ingenieurwesen werden. Eine Sprache wird als sauber beschrieben, die andere als belastet. Das eine stellt man sich als Zukunft vor, das andere als Gepäck aus der Vergangenheit. Diese Geschichten sind emotional befriedigend, weil sie dafür sorgen, dass sich die Geschichte ordentlich anfühlt. Sie führen auch Teams in die Irre, die Systeme unter Einhaltung von Fristen, Budgets, Integrationsbeschränkungen und jetzt einer zusätzlichen Kraft ausliefern müssen, die es vor zehn Jahren noch nicht auf die gleiche Weise gab: KI-Codierungsassistenten und -Agenten.

Sobald die Codegenerierung Teil der täglichen Bereitstellung wird, ändert sich die Frage. Es geht nicht mehr nur darum: „Welche Sprache ist elegant?“ oder „Welche Sprache ist standardmäßig sicher?“ Die schwierigere und praktischere Frage lautet: Wenn ein Team erwartet, dass KI-Systeme beim Schreiben, Refactoring, Benchmarking, Integrieren und Debuggen von Produktionscode helfen, welche Sprache bietet diesen Systemen derzeit die umfangreichste Umgebung, in der sie nützlich sein können? Meine Antwort bleibt C++, und der Kern des Arguments ist weder Nostalgie noch Machismo. Es ist Dichte.

C++ befindet sich immer noch in einer dichteren Welt aus öffentlichem Code, bereitgestellter Infrastruktur, Anbietertools, Plattformbeispielen, Optimierungsfolklore und echten Produktionsnarben als Rust. KI-Modelle lernen aus dieser Dichte. Sie lernen nicht nur Syntax. Sie erfahren, wie Menschen große Systeme zusammengefügt haben, wie sich Build-Dateien entwickelt haben, wie hässliche Integrationen zum Funktionieren gebracht wurden, wie Fehler auf niedriger Ebene diagnostiziert wurden und wie leistungsempfindlicher Code tatsächlich aus Wut und nicht in der Theorie geschrieben wurde. Wenn diese Modelle später gebeten werden, bei der echten Technik zu helfen, kommt es auf die Form dieser historischen Erinnerung an.

Das bedeutet nicht, dass Rust schwach, unseriös oder irrelevant ist. Im Gegenteil, Rust hat einen gesunden Druck in die Systemprogrammierung gebracht. Es machte die Speichersicherheit unübersehbar, verbesserte den Ton vieler technischer Gespräche und führte zu wirklich leistungsstarken Werkzeugen und Bibliotheken. Aber das Vorhandensein der Stärken von Rust löscht nicht automatisch die aktuellen Vorteile von C++ bei der KI-gestützten Bereitstellung aus. Ausgereiftes Ingenieurwesen erfordert oft die gleichzeitige Beherrschung beider Wahrheiten.

Zuerst Beweise, später Slogans

Eine sorgfältige Argumentation beginnt mit der Trennung dessen, was öffentlich beobachtet werden kann, und dem, was abgeleitet werden muss. Öffentliche Datensätze, die in der Codemodellforschung verwendet werden, wie z. B. The Stack, zeigen wesentlich mehr C++ als Rust. Öffentliche Entwicklerumfragen und GitHub-Sprachtrends zeigen weiterhin eine breitere absolute Nutzung von C++ in der gesamten Branche. Die öffentliche KI-Infrastruktur, von SDKs der Anbieter über optimierte Inferenzlaufzeiten bis hin zu mathematischen Bibliotheken auf niedriger Ebene, offenbart immer noch eine Welt, die stark von C und C++ geprägt ist. Öffentliche Benchmarking-Bemühungen wie CRUST-Bench deuten auch darauf hin, dass aktuelle Modelle immer noch Schwierigkeiten haben, konsistent sicheres, idiomatisches Rust in dem starken Sinne zu generieren, den Rust-Communitys schätzen.

Aus diesen Tatsachen ziehen wir eine Schlussfolgerung, kein Dogma. Die Schlussfolgerung ist, dass KI-Systeme derzeit in vielen Systemdomänen eher produktionstaugliches, integrierbares und optimierbares C++ generieren, da die Umgebung für C++ umfangreicher ist. Das ist keine Zauberei. Es ist Belichtung kombiniert mit Feedback. Eine Sprache mit mehr Repositorys, mehr Build-Skripten, mehr Hardware-Beispielen, mehr Anbieterintegrationen, mehr öffentlichen Fehlerbehebungen, mehr Leistungsuntersuchungen und mehr Produktionskriegsgeschichten bietet einem Modell mehr Möglichkeiten, annähernd richtig zu sein, bevor ein menschlicher Ingenieur überhaupt mit der Korrektur beginnt.

Dieser Punkt wird oft abgelehnt, weil er für die neuere Sprache wenig großzügig klingt. Aber es ist keine Beleidigung für Rust, zu sagen, dass es weniger Zeit hatte, Sedimente aus dem öffentlichen Bauwesen anzusammeln. C++ ist seit Jahrzehnten in Betriebssystemen, Browsern, Datenbanken, Medienstapeln, Sicherheitstools, Spiele-Engines, Telekommunikation, wissenschaftlichem Rechnen, eingebetteten Produkten und Finanzsystemen eingebettet. Rost ist schnell und bewundernswert gewachsen, aber Wachstum ist nicht dasselbe wie geologische Tiefe. KI-Modelle absorbieren Tiefe.

Warum die Körpergröße wichtiger ist, als die Leute zugeben

Ingenieure behandeln das Trainingsdatenvolumen manchmal so, als wäre es ein grobes Gesprächsthema. In der Praxis kommt es auf viel menschlichere Weise an. Ein KI-Agent, der in einer Produktionscodebasis arbeitet, erfindet normalerweise keinen perfekten Algorithmus nach den ersten Prinzipien. Es macht etwas Schlimmeres. Dabei kann es sich um das Aktualisieren einer CMake-Datei, die Anpassung an eine Compiler-Beschwerde auf einer Plattform, das Ersetzen eines Hot-Path-Containers, das Umhüllen einer Anbieter-API, das Konvertieren von Bild- oder Tensor-Layouts, das Beheben einer ABI-Nichtübereinstimmung oder darum gehen, ein altes natives Subsystem etwas weniger mühsam zu machen, ohne alles um sich herum kaputt zu machen.

Diese Aufgaben belohnen die Vertrautheit mit gewöhnlichem, unvollkommenem, gelebtem Code. Der Agent profitiert davon, dass er nicht nur saubere Lehrbuchbeispiele gesehen hat, sondern Tausende reale Versuche, angrenzende Probleme zu lösen. C++ bietet Modellen weitaus mehr von diesem Material. Es gibt moderneres C++, mehr veraltetes C++, das langsam repariert wird, mehr Benchmark-gesteuertes C++, peinlicheres C++, das immer noch irgendwie wichtige Unternehmen betreibt, und mehr Beispiele von Menschen, die genau die Art von Kompromissen eingehen, die echte Systeme erfordern.

Aus diesem Grund sind „unordentliche C++-Produktionen“ immer noch wertvolle Trainingsdaten. Manche Ingenieure hören diesen Satz und stellen sich vor, dass er das Gehäuse schwächt. In Wirklichkeit stärkt es es. Produktionssysteme bestehen nicht ausschließlich aus eleganten Greenfield-Modulen. Dazu gehören veraltete Schnittstellen, seltsame ABI-Annahmen, Plattformbedingungen, Hardware-Macken, Teilmigrationen und Code, der überlebt hat, weil er nützlich war, bevor er schön wurde. Wenn ein KI-System viele weitere Beispiele dieser Landschaft in C++ gesehen hat, ist es einfach besser darauf vorbereitet, in einer solchen Landschaft zu helfen.

Es lohnt sich, ein Gegenbeispiel offen anzugeben. Wenn ein Team einen kleinen Greenfield-Dienst mit ausgeprägter Rust-Expertise, klaren Sicherheitsanforderungen, bescheidenen Integrationsanforderungen und keinem umfangreichen nativen Ökosystem um ihn herum aufbaut, ist Rust möglicherweise die bessere lokale Wahl. In dieser Situation ist das Argument der Korpusgröße weniger ausschlaggebend, da der umgebende technische Kontext einfacher ist und das menschliche Team das System innerhalb eines engeren Komplexitätsbereichs halten kann. Der Punkt ist nicht, dass C++ jedes Argument gewinnt. Der Punkt ist, dass C++ für KI-Systeme zunehmend die einfachere Sprache wird, mit der KI-Systeme effektiv helfen können, wenn das Problem älter, seltsamer, leistungsempfindlicher und stärker mit der vorhandenen nativen Infrastruktur verknüpft wird.

Die Welt der KI-Infrastruktur ist immer noch C++-geprägt

Selbst wenn wir das Trainingsdatenvolumen völlig ignorieren würden, gäbe es immer noch eine zweite Kraft, die den Standard in Richtung C++ zieht: Die Infrastruktur, die modernen KI-Produkten zugrunde liegt, bleibt stark nativ. CUDA, optimierte Mathematikbibliotheken, ONNX Runtime-Interna, oneDNN, OpenVINO, Tokenizer-Implementierungen, Multimedia-Vorverarbeitungspipelines, Modell-Beschleuniger, SDKs von Hardwareanbietern und viele Bereitstellungslaufzeiten sind entweder in C oder C++ geschrieben oder stellen dort ihre wichtigsten Schnittstellen zur Verfügung. Das bedeutet nicht, dass Rust sie nicht anrufen kann. Das bedeutet, dass der kürzeste Weg durch die Landschaft normalerweise immer noch ein C- oder C++-Pfad ist.

Das ist wichtig, denn KI-Codierungsagenten sind im luftleeren Raum nicht nützlich. Sie sind in Abhängigkeitsdiagrammen nützlich. Ein Modell, das dabei helfen soll, eine Laufzeit zu integrieren, einen Build zu debuggen, einen Hot Path zu optimieren oder den Besitz über die SDK-Grenze eines Anbieters hinaus zu ermitteln, ist von Vorteil, wenn es viele benachbarte Beispiele in derselben Sprachfamilie gesehen hat. C++ profitiert bei den meisten leistungskritischen KI-Infrastrukturarbeiten immer noch mehr von dieser Umgebungsvertrautheit als Rust.

Hier wird auch das Gespräch über Feedbackschleifen wichtig. KI-generierter Code wird erst dann wirklich wertvoll, wenn Menschen ihn schnell verifizieren können. C++ bietet Teams in diesen Bereichen oft eine umfassendere lokale Überprüfung, da das Ökosystem rund um Benchmarking, Profiling, Wiedergabe, Sanitizer, Hardwarezähler und Low-Level-Diagnose so ausgereift ist. Wenn ein Agent eine Änderung in einem C++-Inferenzpfad vorschlägt, kann ein Team diese häufig kompilieren, ein Profil erstellen, das Zuordnungsverhalten überprüfen, Latenzverteilungen vergleichen und schnell iterieren. Auch Rust verfügt absolut über starke Tools, aber in vielen KI-nahen nativen Systemen macht die kombinierte Dichte an Bibliotheken, Beispielen, Profilern und vorhandener Praxis C++ immer noch zum einfacheren Ort, um enge Human-in-the-Loop-Korrekturschleifen auszuführen.

Warum Teams mit C++ oft schneller vorankommen, auch wenn Rust sauberer aussieht

Das ist der Punkt, der die Ideologie beleidigt, weil er in Bezug auf Sauberkeit unhöflich klingt. Rost sieht auf dem Whiteboard oft sauberer aus. Das Eigentum ist explizit. Der Compiler schützt wichtige Fehler. Die Kultur der Korrektheit ist bewundernswert. Aber Produktionsgeschwindigkeit ist nicht dasselbe wie Spracheleganz. Die tatsächliche Liefergeschwindigkeit ergibt sich aus der gesamten Schleife: vorhandene Codebasis, verfügbare Bibliotheken, Talentpool, Debugging-Tools, Bereitstellungsbeschränkungen, Qualität der KI-Unterstützung und die Kosten für eine weitere Änderung im nächsten Monat.

C++ gewinnt derzeit in vielen Systemen des KI-Zeitalters diese umfassendere Schleife, da Teams mehr von der umgebenden Welt abfragen können, ohne die Sprache zu verlassen. Sie können alte native Bibliotheken integrieren, Profiler anbinden, die im Hinblick auf native Performance-Arbeiten erstellt wurden, Allokatoren optimieren, plattformspezifische Funktionen nutzen und auf eine viel größere Menge öffentlicher Beispiele zurückgreifen, wenn etwas schief geht. KI-Assistenten profitieren von genau der gleichen Realität. Wenn die Welt um das Modell herum dicht und weit gereist ist, verbessern sich die Rohentwürfe des Modells schneller.

Stellen Sie sich vor, dass zwei Teams einen latenzempfindlichen Inferenzdienst mit einer benutzerdefinierten Vorverarbeitung, einer komplizierten Bereitstellungsmatrix und der Notwendigkeit einer wiederholten Leistungsoptimierung erstellen. Das Rust-Team produziert möglicherweise eine kleinere Anzahl von Speichersicherheitsfehlern, und das ist nicht trivial. Aber wenn das C++-Team das Ökosystem direkter integrieren, stärkere KI-Vorschläge in der vorhandenen Codebasis erhalten und Leistungsänderungen mit ausgereiften nativen Tools schneller überprüfen kann, könnte das Gesamtergebnis der Bereitstellung immer noch zugunsten von C++ ausfallen. Aus geschäftlicher Sicht ist das wichtiger als die Frage, ob eine Sprache online eine philosophische Auseinandersetzung gewonnen hat.

Ein nützliches Gegenbeispiel hält uns ehrlich. Wenn das Hauptrisiko in einem Projekt nicht die Integration oder Leistungsentwicklung ist, sondern die Speichersicherheit in einem neuen Dienst mit relativ einfachen Abhängigkeiten, kann Rust durchaus bessere organisatorische Ergebnisse erzielen. Der Fehler besteht darin, diese Wahrheit zu nehmen und sie wahllos in jedes Problem mit KI-nahen Systemen zu exportieren. Sprachen gewinnen im Kontext, nicht in Predigten.

Was Rust immer noch richtig macht

Rust verdient Respekt, und das Argument für C++ ist schwächer, wenn es Rust karikiert. Rust ist hervorragend darin, unsichere Annahmen sichtbar zu machen. Es schafft eine strenge Disziplin in Bezug auf Eigentum und Lebensdauer. Es ist oft eine überzeugende Wahl für eine Greenfield-Infrastruktur, bei der Korrektheit und Wartbarkeit wichtiger sind als die Kompatibilität mit einer bestehenden nativen Welt. In einigen Teams verbessert Rust auch die Klarheit bei der Einstellung, da die Codebasis selbst eine gewisse Ernsthaftigkeit der Technik erzwingt.

Es ist auch wichtig, deutlich zu sagen, dass C++ nicht standardmäßig gewinnt, nur weil es älter ist. Undiszipliniertes C++ bleibt gefährlich. Wenn ein Team über eine schwache Bewertungskultur, keine Profilierungsgewohnheiten, schlechte Tests und keinen Respekt vor der Beobachtbarkeit verfügt, können größere Korpora und umfassendere Tools das Team nicht retten. KI-Systeme können dieses Chaos ebenso leicht verstärken, wie sie gute Technik beschleunigen können. Der eigentliche Anspruch ist enger und praktischer: Angesichts disziplinierter Teams, die leistungsempfindliche, integrationsintensive Systemprobleme der KI-Ära lösen, ist C++ auch heute noch die stärkere Standardlösung, weil Agenten, Tools und die Schwerkraft des Ökosystems dies alles verstärken.

Aus diesem Grund bevorzuge ich den Begriff „Standardwette“ gegenüber dem Begriff „Universalgewinn“. Eine Standardwette ist das, was Sie wählen, wenn sich die Beweislast noch nicht anderswo verlagert hat. Rust kann diese Verschiebung in bestimmten Projekten erreichen. Aber C++ hat immer noch mehr Beweise für sich, wenn die Arbeit stark mit der nativen KI-Infrastruktur, geringer Leistung, langlebigen Produktionssystemen oder der Art von Codebasis verknüpft ist, die KI-Agenten in großer Zahl öffentlich gesehen haben.

Eine praktische Art zu entscheiden

Wenn der Hot Path nativ ist, das Abhängigkeitsdiagramm nativ ist, die Profilierungsgeschichte wichtig ist und Sie erwarten, dass KI-Assistenten in chaotischem echten Produktionscode helfen, verdient C++ Ihre erste ernsthafte Sprachdiskussion. Wenn das System auf der grünen Wiese ist, der Sicherheitsnachweis dominiert, das umgebende Ökosystem bereits Rust-förmig ist und das Problem nicht stark von alten einheimischen Schichten abhängt, wird Rust attraktiver. Wenn das System beide Welten umfasst, was viele tun, ist die ausgereifte Antwort oft eher eine Hybridarchitektur als eine Stammesreinheit.

Dieser Rahmen beruhigt das Gespräch, weil er die Entscheidung auf die Arbeit und nicht auf die Identität zurückführt. Eine native Inferenzlaufzeit innerhalb einer vorhandenen C++-Plattform stellt nicht das gleiche Problem dar wie ein neuer Steuerungsebenendienst. Eine Medienpipeline mit geringer Latenz ist nicht das gleiche Problem wie eine Backend-API. Eine modellbedienende Edge-Komponente ist nicht das gleiche Problem wie eine kettennative Zustandsübergangs-Engine. Sobald wir das eigentliche Werk benennen, sieht die Sprachwahl normalerweise weniger ideologisch und offensichtlicher aus.

Es hat auch einen menschlichen Nutzen, die Entscheidung auf diese Weise zu treffen. Teams werden kooperativer, wenn sie aufhören zu fragen, welche Sprache Bewunderung verdient, und anfangen zu fragen, welche Sprache dem aktuellen System die besten Chancen bietet, zuverlässig, verständlich und verbesserungsfähig zu werden. Die KI-Unterstützung macht dies noch wichtiger. Agenten sind dann mächtig, wenn sie in eine Kultur der Verifizierung eingebettet sind, und nicht, wenn sie dazu verwendet werden, die Sprachfandom mit synthetischem Selbstvertrauen zu schmücken.

Die wahre Chance

Die tiefere Chance im KI-Zeitalter besteht nicht nur darin, dass Agenten Code schreiben können. Sie können jetzt an der gesamten Feedback-Schleife rund um ausgereifte Systeme teilnehmen: alten Code lesen, Änderungen vorschlagen, Benchmarks verbessern, Profiler-Hinweise aufdecken, grobe Ideen in kompilierbare Experimente umsetzen und Ingenieuren dabei helfen, schneller als zuvor vom Verdacht zur Messung überzugehen. In dieser Welt ist die Sprache, die am meisten profitiert, nicht unbedingt diejenige mit der schönsten theoretischen Geschichte. Es ist das Land mit dem dichtesten Netz an öffentlicher, praktischer und kampferprobter Realität.

Heutzutage ist diese Sprache für eine große Klasse schwerwiegender Systemprobleme immer noch C++. Und das sind gute Nachrichten, nicht weil die Branche aufhören sollte, von Rust zu lernen, sondern weil Teams den riesigen Bestand an vorhandenem nativem Wissen nutzen können, anstatt so zu tun, als wäre es verschwunden, sobald die KI eintraf. Die produktivste Haltung ist nicht der Triumphalismus. Es ist Dankbarkeit. C++ hat über Jahrzehnte echten technischen Speicher angesammelt, und KI-Systeme machen diesen Speicher jetzt einfacher zu nutzen. Kluge Teams werden davon profitieren.

Hands-on Lab: Erstellen und verbessern Sie eine native Scoring-Pipeline

Wenn ein Artikel über die Sprachwahl im KI-Zeitalter keinen Code enthält, besteht die Gefahr, dass er zu einer Predigt wird.

Lassen Sie uns also ein kleines natives C++-Dienstprogramm erstellen, wie KI-Agenten in echten Unternehmen ständig verbessern müssen: eine Textbewertungspipeline, die Daten lädt, einfache Funktionen berechnet, die Ergebnisse sortiert und die obersten Zeilen druckt.

Es ist absichtlich bescheiden. Der Großteil der Produktionstechnik ist 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";
    }
}

Bauen

Unter Linux oder macOS:

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

Unter Windows mit MSVC:

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

Warum dieses kleine Programm nützlich ist

Denn genau in diesem Code wird KI-gestütztes Engineering greifbar:

• es ist einheimisch
• es berührt Saiten und Erinnerung
• es hat eine messbare Laufzeit
• es kann profiliert werden
• es kann schrittweise verbessert werden

Das ist heute der wahre Lebensraum vieler C++-Agenten: keine großen Demonstrationen, sondern gewöhnliche native Programme, die besser werden müssen, ohne neu erfunden zu werden.

Testaufgaben für Enthusiasten

Wenn Sie den Artikel in eine praktische Übung umwandeln möchten, versuchen Sie Folgendes:

1. Bitten Sie Ihren bevorzugten Programmieragenten, das Programm zu optimieren, ohne die Ausgabe zu ändern. Überprüfen Sie, ob dadurch doppelte Durchgänge oder unnötige Provisorien reduziert werden.
2. Fügen Sie separate Zeitvorgaben für das Laden, Bewerten und Sortieren von Dateien hinzu. Überprüfen Sie, wo die Zeit wirklich vergeht.
3. Ersetzen Sie die Eingabe durch eine Million Zeilen und vergleichen Sie die Qualität der von verschiedenen Agenten vorgeschlagenen Optimierungen.
4. Portieren Sie das Dienstprogramm auf Rust und vergleichen Sie die Erfahrungen ehrlich: Was fühlte sich klarer an, was fühlte sich schwerer an und welche umgebenden Werkzeuge fühlten sich für genau diese Aufgabe ausgereifter an.
5. Führen Sie die C++-Version unter einem Profiler aus und notieren Sie, ob Ihre erste Vermutung über den Hotspot tatsächlich richtig war.

Dies ist eine kleine Übung, aber gerade deshalb ist sie nützlich. Die meisten technischen Debatten werden wahrheitsgemäßer, wenn sie gezwungen sind, den Kontakt mit einem kleinen echten Programm zu überstehen.

Zusammenfassung

Rust verdient den Respekt, den es erhält. Es erhöhte den Standard für Sicherheitsgespräche und gab der Systemprogrammierung einen gesünderen Satz an Standardeinstellungen. Aber das KI-Zeitalter belohnt nicht nur Zahlungsausfälle. Es belohnt die Sprache, die sich im Zentrum des größten lebenden Korpus echten Codes, des tiefsten Ökosystems von Low-Level-Integrationen, der reichhaltigsten Optimierungskultur und der schnellsten praktischen Schleife vom generierten Entwurf bis zum messbaren Produktionsergebnis befindet. Das beschreibt C++ heute noch stärker als Rust.

Das macht C++ nicht moralisch überlegen und Rust nicht irrelevant. Es bedeutet lediglich, dass KI-Agenten bei vielen schwerwiegenden nativen Systemproblemen immer noch nützlicheres Terrain unter ihren Füßen haben, wenn die Zielwelt C++ ist. Teams, die dies verstehen, können ohne Drama bessere Entscheidungen treffen. Sie können von Rust lernen, wo Rust am stärksten ist, und dennoch den riesigen angesammelten Speicher von C++ dort nutzen, wo dieser Speicher wirtschaftlich am wertvollsten ist.

Referenzen

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-Entwicklerumfrage 2023: https://survey.stackoverflow.co/2023
4. Stack Overflow Developer Survey 2025-Technologieabschnitt: https://survey.stackoverflow.co/2025/technology/
5. Die Stack-Datensatzkarte: https://huggingface.co/datasets/bigcode/the-stack
6. Das Stapelpapier: https://arxiv.org/abs/2211.15533
7. ICLR 2025-Papier über die Auswirkungen von Codedaten im Vortraining: https://openreview.net/pdf?id=zSfeN1uAcx
8. CRUST-Bench: Ein umfassender Benchmark für die C-to-Safe-Rust-Transpilation: https://arxiv.org/abs/2504.15254
9. CUDA C++-Programmierhandbuch: 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-Dokumentation: https://docs.pytorch.org/cppdocs/frontend.html
12. C++-Kernrichtlinien: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines