Warum C++ in der KI-Ära immer noch besser ist als Rust

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 umfassendste 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 Syntax, wie Menschen große Systeme zusammenfügten, wie sich Build-Dateien entwickelten, 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 Lieferung 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 wie The Stack verwendet werden, 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, vom Anbieter SDKs über optimierte Inferenzlaufzeiten bis hin zu Low-Level-Mathematikbibliotheken, 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, durchweg sichere, idiomatische Rust in dem starken Sinne zu generieren, den Rust-Gemeinschaften schätzen.

Aus diesen Tatsachen ziehen wir eine Schlussfolgerung, kein Dogma. Die Schlussfolgerung ist, dass KI-Systeme derzeit in vielen Systemdomänen mit größerer Wahrscheinlichkeit produktionsnützliche, integrierbare und optimierbare 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. Rust 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 eines 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, saubere Lehrbuchbeispiele und Tausende realer Lösungsversuche für angrenzende Probleme gesehen zu haben. C++ bietet Modellen weitaus mehr von diesem Material. Es gibt das modernere C++, das veraltete C++, das langsam repariert wird, das eher auf Benchmarks basierende C++, das peinlichere C++, das immer noch irgendwie wichtige Geschäfte betreibt, und mehr Beispiele von Menschen, die genau die Art von Kompromissen eingehen, die echte Systeme erfordern.

Aus diesem Grund sind „chaotische Produktion C++“ 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 Legacy-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 in C++ viele weitere Beispiele dieser Landschaft 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 in einem engeren Komplexitätsbereich halten kann. Der Punkt ist nicht, dass C++ jedes Argument gewinnt. Der Punkt ist, dass C++ für KI-Systeme immer einfacher wird, wenn das Problem älter, seltsamer, leistungsempfindlicher und stärker mit der vorhandenen nativen Infrastruktur verknüpft wird.

Die KI Infrastrukturwelt 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 unter modernen KI-Produkten bleibt stark nativ. CUDA, optimierte Mathematikbibliotheken, ONNX Runtime Interna, oneDNN, OpenVINO, Tokenizer-Implementierungen, Multimedia-Vorverarbeitungspipelines, Modell-Serving-Beschleuniger, Hardwareanbieter SDKs und viele Bereitstellungslaufzeiten sind entweder in C oder C++ geschrieben oder stellen dort ihre schwerwiegendsten Schnittstellen zur Verfügung. Dies bedeutet nicht, dass Rust sie nicht aufrufen kann. Das bedeutet, dass der kürzeste Weg durch die Landschaft immer noch normalerweise ein C- oder C++-Pfad ist.

Das ist wichtig, weil KI-Codierungsagenten im luftleeren Raum nicht nützlich sind. 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 Eigentumsverhältnisse über die Grenzen eines Herstellers SDK hinweg 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 überprüfen können. C++ bietet Teams häufig eine umfassendere lokale Überprüfung in diesen Bereichen, 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. Rust verfügt ebenfalls über absolut leistungsstarke Tools, aber in vielen an KI angrenzenden nativen Systemen ist C++ aufgrund der kombinierten Dichte an Bibliotheken, Beispielen, Profilern und vorhandener Praxis immer noch der einfachere 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. Rust 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 Bereitstellungsgeschwindigkeit ergibt sich aus der gesamten Schleife: vorhandene Codebasis, verfügbare Bibliotheken, Talentpool, Debugging-Tools, Bereitstellungsbeschränkungen, KI-Unterstützungsqualität und die Kosten für eine weitere Änderung im nächsten Monat.

C++ gewinnt derzeit diese breitere Schleife in vielen Systemen der KI-Ära, weil Teams mehr von der umgebenden Welt erfragen 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 schneller mit ausgereiften nativen Tools ü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 die Speichersicherheit in einem neuen Dienst mit relativ einfachen Abhängigkeiten das größte Risiko darstellt, kann Rust durchaus zu besseren organisatorischen Ergebnissen führen. Der Fehler besteht darin, diese Wahrheit zu nehmen und sie wahllos in jedes KI-angrenzende Systemproblem 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 bestimmte Art von technischer Ernsthaftigkeit erzwingt.

Es ist auch wichtig, deutlich zu sagen, dass das Alter allein nicht ausreicht. Undiszipliniert bleibt C++ 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 der Tatsache, dass disziplinierte Teams leistungsempfindliche, integrationsintensive Systemprobleme aus der KI-Ära lösen, ist C++ auch heute noch die stärkere Standardlösung, da Agenten, Tools und die Schwerkraft des Ökosystems sie alle 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 sich diese Verschiebung in bestimmten Projekten verdienen. Aber C++ beginnt immer noch mit mehr Beweisen 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ßem Umfang ö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 Ihnen 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 natürlichen 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 ein 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. 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 in der KI-Ära besteht darin, dass Agenten jetzt an der gesamten Feedbackschleife rund um ausgereifte Systeme teilnehmen können: alten Code lesen, Änderungen vorschlagen, Benchmarks verbessern, Profiler-Hinweise aufdecken, grobe Ideen in kompilierbare Experimente umsetzen und Ingenieuren 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.

Heute ist diese Sprache für eine große Klasse schwerwiegender Systemprobleme immer noch C++. Das ist eine gute Nachricht, denn Teams können den riesigen Bestand an vorhandenem nativem Wissen nutzen und gleichzeitig weiterhin von Rust lernen. Die produktivste Haltung ist nicht der Triumphalismus. Es ist Dankbarkeit. C++ hat jahrzehntelang 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 der KI-Ära keinen Code enthält, besteht die Gefahr, dass er zu einer Predigt wird.

Erstellen wir also ein kleines natives C++-Dienstprogramm von der Art, wie KI Agenten in realen Unternehmen ständig verbessern müssen: eine Textbewertungspipeline, die Daten lädt, einfache Funktionen berechnet, die Ergebnisse sortiert und die oberen 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

Am Linux oder macOS:

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

Am Windows mit MSVC:

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

Warum dieses kleine Programm nützlich ist

Denn es ist genau die Art von Code, bei der KI-unterstütztes Engineering greifbar wird:

• 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 eigentliche Lebensraum vieler C++-Agenten: 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 die KI-Ära 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 heute noch C++ stärker als Rust.

Das macht C++ nicht moralisch überlegen, und es macht Rust nicht irrelevant. Es bedeutet einfach, dass KI-Agenten bei vielen schwerwiegenden Problemen mit nativen Systemen 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 trotzdem den riesigen angesammelten Speicher von C++ 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-KI-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 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.KI/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

    Wie das aussieht, wenn das System bereits unter Druck steht

C++ versus rust in Systemen der KI-Ära wird in der Regel genau in dem Moment dringend, in dem ein Team auf ein ruhigeres Quartal gehofft hat. Ein Feature steht den Kunden bereits zur Verfügung, oder eine Plattform weist bereits interne Abhängigkeiten auf, und das System hat diese bestimmte Woche ausgewählt, um zu offenbaren, dass seine elegante Theorie und sein Laufzeitverhalten höflich getrennte Leben geführt haben. Aus diesem Grund beginnt so viel ernsthafte Ingenieursarbeit mit der Versöhnung. Das Team muss das, was das System seiner Meinung nach tut, mit dem in Einklang bringen, was das System tatsächlich unter Last, bei Veränderungen und unter Fristen tut, die alle etwas kreativer und etwas weniger klug machen.

Bei der nativen Infrastrukturplanung sind in der Regel große Legacy-Plattformen, leistungsempfindliche KI-Backends und Modernisierungsprogramme mit mehreren Sprachen die wichtigsten Fälle. Solche Situationen haben technische, budgetäre, vertrauenswürdige, Roadmap- und manchmal auch Reputationsfolgen. Ein technisches Problem wird politisch größer, sobald mehrere Teams darauf angewiesen sind und niemand so recht erklären kann, warum es sich innerhalb der Mauern immer noch wie ein Waschbär verhält: nachts laut, schwer zu lokalisieren und teuer zu ignorieren.

Deshalb empfehlen wir, das Problem aus der Sicht des Betriebsdrucks und der Förderrealität zu betrachten. Ein Entwurf kann theoretisch schön und funktionell ruinös sein. Ein anderes Design kann fast langweilig sein und das Produkt dennoch jahrelang weiterbringen, weil es messbar, reparierbar und ehrlich in Bezug auf seine Kompromisse ist. Ernsthafte Ingenieure lernen, die zweite Kategorie zu bevorzugen. Es führt zu weniger epischen Reden, aber auch zu weniger Notfallrückblicken, bei denen jeder im Passiv spricht und sich niemand daran erinnert, wer die Abkürzung genehmigt hat.

Praktiken, die dauerhaft gut altern

Die erste dauerhafte Praxis besteht darin, einen repräsentativen Pfad ständig zu messen. Teams sammeln oft zu viele vage Telemetriedaten und zu wenig Entscheidungsqualitätssignale. Wählen Sie den Weg, der wirklich wichtig ist, messen Sie ihn wiederholt und lassen Sie die Diskussion nicht in dekoratives Geschichtenerzählen abdriften. Bei der Arbeit rund um C++ im Vergleich zu Rust in Systemen der KI-Ära sind die nützlichen Messgrößen normalerweise Liefergeschwindigkeit, Interop-Kosten, Werkzeugreife und Laufzeitbeobachtbarkeit. Sobald diese sichtbar sind, werden die restlichen Entscheidungen menschlicher und weniger mystisch.

Die zweite dauerhafte Praxis besteht darin, Beweise von Versprechen zu trennen. Ingenieure werden oft unter Druck gesetzt, zu sagen, dass eine Richtung richtig ist, bevor das System zu dieser Schlussfolgerung gelangt ist. Widerstehen Sie diesem Druck. Erstellen Sie zunächst einen engen Beweis, insbesondere wenn es um Kunden oder Geld geht. Eine kleine verifizierte Verbesserung hat einen größeren kommerziellen Wert als ein großes, unbestätigtes Ziel. Das klingt offensichtlich, bis eine Überprüfung am Quartalsende eine Hypothese in eine Frist verwandelt und die gesamte Organisation anfängt, Optimismus wie ein Planungsartefakt zu behandeln.

Die dritte dauerhafte Praxis besteht darin, Empfehlungen in der Sprache des Eigentümers zu verfassen. Ein Absatz, in dem es heißt „Leistung verbessern“ oder „Grenzen stärken“, ist emotional angenehm und operativ nutzlos. Ein Absatz, der besagt, wer was in welcher Reihenfolge und mit welcher Rollback-Bedingung ändert, ist derjenige, der am Montagmorgen tatsächlich überlebt hat. Hier scheitern viele technische Texte. Es möchte mehr fortgeschritten klingen als planbar sein.

Gegenbeispiele, die Zeit sparen

Eines der häufigsten Gegenbeispiele sieht so aus: Das Team hat einen deutlichen lokalen Erfolg, geht davon aus, dass das System nun verstanden ist, und skaliert die Idee dann in eine viel anspruchsvollere Umgebung, ohne die Messdisziplin zu verbessern. Das ist das technische Äquivalent dazu, in einem Hotelpool schwimmen zu lernen und dann einen selbstbewussten TED-Vortrag über das Wetter auf See zu halten. Wasser ist Wasser, solange es keins mehr ist.

Ein weiteres Gegenbeispiel ist die Werkzeuginflation. Ein neuer Profiler, eine neue Laufzeit, ein neues Dashboard, ein neuer Agent, eine neue Ebene der Automatisierung, ein neuer Wrapper, der verspricht, den alten Wrapper zu harmonisieren. Keines dieser Dinge ist von Natur aus schlecht. Das Problem ist, was passiert, wenn von ihnen verlangt wird, eine Grenze zu kompensieren, die niemand klar benannt hat. Das System wird dann instrumentierter, eindrucksvoller und nur gelegentlich verständlicher. Das spüren Käufer sehr schnell. Sie formulieren es vielleicht nicht so, aber sie riechen, wenn ein Stapel zu einem teuren Ersatz für eine Entscheidung geworden ist.

Das dritte Gegenbeispiel besteht darin, die menschliche Überprüfung als einen Fehler der Automatisierung zu betrachten. In realen Systemen ist die menschliche Überprüfung oft die Kontrolle, die die Automatisierung kommerziell akzeptabel hält. Reife Teams wissen, wo sie aggressiv automatisieren und wo sie Genehmigungen oder Interpretationen sichtbar halten müssen. Unreife Teams möchten, dass die Maschine alles kann, weil „alles“ auf einer Folie effizient klingt. Dann kommt es zum ersten schwerwiegenden Vorfall, und plötzlich wird die manuelle Überprüfung mit der Aufrichtigkeit einer Konvertierungserfahrung wiederentdeckt.

Ein Liefermuster, das wir empfehlen

Wenn die Arbeit gut gemacht wird, sollte das erste Ergebnis Stress reduzieren, indem es dem Team eine technische Lektüre gibt, die stark genug ist, um nicht mehr im Kreis zu streiten. Danach sollte die nächste begrenzte Implementierung einen entscheidenden Pfad verbessern und der erneute Test sollte die Richtung sowohl für die Technik als auch für die Führung lesbar machen. Diese Reihenfolge ist wichtiger als die genaue Wahl des Werkzeugs, denn sie ist es, die technisches Können in Vorwärtsbewegung umsetzt.

In der Praxis empfehlen wir einen engen ersten Zyklus: Artefakte sammeln, eine eindeutige Diagnose erstellen, eine begrenzte Änderung versenden, den tatsächlichen Pfad erneut testen und die nächste Entscheidung im Klartext verfassen. Klare Sprache ist wichtig. Ein Käufer bereut die Klarheit selten. Ein Käufer bereut es oft, beeindruckt zu sein, bevor die Quittungen eintreffen.

Auch hier kommt es auf den Ton an. Starke technische Arbeit sollte so klingen, als hätte sie die Produktion schon einmal erlebt. Ruhig, präzise und ein wenig amüsiert über den Hype, anstatt davon genährt zu werden. Dieser Ton trägt das Betriebssignal. Es zeigt, dass das Team die alte Wahrheit der Systemtechnik versteht: Maschinen sind schnell, Roadmaps sind fragil und früher oder später kommt die Rechnung für jede Annahme, die poetisch bleiben durfte.

Die Checkliste, die wir verwenden würden, bevor wir dies als „fertig“ bezeichnen

Bei der lokalen Infrastrukturplanung ist Bereitschaft keine Stimmung. Es ist eine Checkliste mit Konsequenzen. Bevor wir die Umgehung von C++ im Vergleich zu Rust in Systemen der KI-Ära als bereit für eine breitere Einführung bezeichnen, möchten wir, dass ein paar Dinge bestmöglich langweilig werden. Wir wollen einen Pfad, der sich unter repräsentativer Last vorhersehbar verhält. Wir wollen eine Reihe von Messungen, die sich nicht widersprechen. Wir möchten, dass das Team weiß, wo die Grenze liegt und was es bedeuten würde, sie zu durchbrechen. Und wir möchten, dass das Ergebnis der Arbeit klar genug ist, dass jemand außerhalb des Implementierungsraums dennoch eine fundierte Entscheidung daraus treffen kann.

Die Checkliste, die wir verwenden würden, bevor wir dies als „fertig“ bezeichnen

Hier erfahren die Teams auch, ob sie das eigentliche Problem gelöst oder lediglich Kompetenzen in dessen allgemeiner Umgebung geübt haben. Viele technische Bemühungen erweisen sich als erfolgreich, bis jemand nach Wiederholbarkeit, Produktionsnachweisen oder einer Entscheidung fragt, die sich auf das Budget auswirkt. In diesem Moment verschwimmt das schwache Werk und das starke Werk wird seltsam deutlich. Einfach ist gut. „Einfach“ bedeutet normalerweise, dass das System nicht mehr auf Charisma setzt.

Wie wir empfehlen, über das Ergebnis zu sprechen

Die abschließende Erklärung sollte kurz genug sein, um eine Führungsbesprechung zu überstehen, und konkret genug, um eine technische Überprüfung zu überstehen. Das ist schwieriger als es klingt. Eine zu technische Sprache verbirgt die Reihenfolge. Eine zu vereinfachte Sprache birgt Risiken. Der richtige Mittelweg besteht darin, den Weg, die Beweise, die begrenzte Veränderung und den nächsten empfohlenen Schritt auf eine Weise zu beschreiben, die eher ruhig als triumphierend klingt.

Wir empfehlen einen solchen Aufbau. Sagen Sie zunächst, welcher Pfad bewertet wurde und warum er wichtig war. Zweitens: Sagen Sie, was an diesem Weg falsch oder unsicher war. Drittens sagen Sie, was geändert, gemessen oder validiert wurde. Viertens sagen Sie, was noch ungelöst ist und was die nächste Investition bringen würde. Diese Struktur funktioniert, weil sie sowohl die Technik als auch das Kaufverhalten respektiert. Ingenieure wollen Einzelheiten. Käufer wollen eine Reihenfolge. Jeder möchte weniger Überraschungen, auch die Leute, die so tun, als würden sie sie genießen.

Der verborgene Vorteil dieser Art des Sprechens ist kultureller Natur. Teams, die technische Arbeiten klar erklären, führen diese in der Regel auch klarer aus. Sie hören auf, Mehrdeutigkeit als Raffinesse zu betrachten. Es wird schwieriger, sie mit Fachjargon zu beeindrucken und ihnen bei schwierigen Systemen leichter zu vertrauen. Das ist eine der am meisten unterschätzten Formen der technischen Reife.

Was wir immer noch nicht fälschen würden

Auch nach der Verbesserung des Systems behalten erfahrene Teams die Unsicherheit bei der Planung der nativen Infrastruktur bei. Schwache Messungen erfordern klarere Beweise, harte Grenzen erfordern eine klare Sprache und ruhigere Demos erfordern echte Einsatzbereitschaft. Eine gewisse Unsicherheit muss verringert werden; einige müssen ehrlich benannt werden. Durch die Verwechslung dieser beiden Berufe werden seriöse Projekte zu teuren Gleichnissen.

Die gleiche Regel gilt für Entscheidungen rund um C++ versus Rust in Systemen der KI-Ära. Wenn einem Team immer noch ein reproduzierbarer Benchmark, ein vertrauenswürdiger Rollback-Pfad oder ein klarer Eigentümer für die kritische Schnittstelle fehlt, dann ist das nützlichste Ergebnis möglicherweise ein schärferes Nein oder ein engerer nächster Schritt statt eines größeren Versprechens. Diese Disziplin sorgt dafür, dass die technische Arbeit mit der Realität in Einklang steht, die sie verbessern soll.

Es ist eine seltsame Erleichterung, auf diese Weise zu arbeiten. Sobald das System nicht mehr auf optimistisches Storytelling angewiesen ist, wird das technische Gespräch einfacher, auch wenn die Arbeit weiterhin hart bleibt. Und in der Produktion gilt das oft als Nebensache.

Feldnotizen aus einer echten technischen Überprüfung

Bei der Bereitstellung von C++-Systemen wird die Arbeit ernst, wenn die Demo auf echte Lieferung, echte Benutzer und echte Betriebskosten trifft. Das ist der Moment, in dem eine ordentliche Idee anfängt, sich wie ein System zu verhalten, und Systeme haben bekanntermaßen einen trockenen Sinn für Humor. Es ist ihnen egal, wie elegant das Kickoff-Deck aussah. Sie kümmern sich um Grenzen, Fehlermodi, Rollout-Pfade und darum, ob irgendjemand den nächsten Schritt erklären kann, ohne eine neue Mythologie rund um den Stack zu erfinden.

Für Why C++ Still Beats Rust in the KI Era stellt sich in der Praxis die Frage, ob es einen stärkeren Lieferweg für einen Käufer schafft, der bereits Druck auf eine Roadmap, eine Plattform oder eine Sicherheitsüberprüfung hat. Dieser Käufer braucht keinen in Nebel gehüllten Vortrag. Sie benötigen eine technische Lektüre, die sie verwenden können.

Was wir zuerst inspizieren würden

Wir würden mit einem repräsentativen Pfad beginnen: native Inferenz, Profilierung, HFT-Pfade, DEX-Systeme und C++/Rust-Modernisierungsoptionen. Dieser Weg sollte schmal genug sein, um ihn zu messen, und breit genug, um die Wahrheit ans Licht zu bringen. Der erste Durchgang sollte das Zuordnungsverhalten, die p99-Latenz, den Profilnachweis, die ABI-Reibung und das Release-Vertrauen erfassen. Wenn diese Signale nicht verfügbar sind, handelt es sich bei dem Projekt größtenteils immer noch um eine Meinung, die einen Laborkittel trägt, und die Meinung hat eine lange Tradition darin, sich selbst als Strategie darzustellen.

Das erste nützliche Artefakt ist ein natives System-Read mit Benchmarks, Profiling-Beweisen und einem zielgerichteten Implementierungsplan. Es sollte das System so zeigen, wie es sich verhält, und nicht so, wie alle gehofft hatten, dass es sich in der Planungsbesprechung verhalten würde. Ein Trace, eine Wiederholung, ein kleiner Benchmark, eine Richtlinienmatrix, ein Parser-Fixture oder ein wiederholbarer Test erzählen die Geschichte oft schneller als eine andere abstrakte Architekturdiskussion. Gute Artefakte sind wunderbar unhöflich. Sie unterbrechen das Wunschdenken.

Ein Gegenbeispiel, das Zeit spart

Der kostspielige Fehler besteht darin, mit einer Lösung zu antworten, die größer ist als der erste nützliche Beweis. Ein Team erkennt Risiken oder Verzögerungen und greift sofort nach einer neuen Plattform, einer Neufassung, einem umfassenden Refactoring oder einem beschaffungsfreundlichen Dashboard mit einem Namen, der nach Yoga klingt. Manchmal ist dieser Maßstab gerechtfertigt. Sehr oft ist es eine Möglichkeit, die Messung zu verschieben.

Der bessere Zug ist kleiner und schärfer. Benennen Sie die Grenze. Erfassen Sie Beweise. Ändern Sie eine wichtige Sache. Testen Sie denselben Pfad erneut. Entscheiden Sie dann, ob die nächste Investition eine größere Investition verdient. Dieser Rhythmus ist weniger dramatisch als ein Transformationsprogramm, aber er übersteht tendenziell den Kontakt mit Budgets, Veröffentlichungskalendern und Produktionsvorfällen.

Das von uns empfohlene Liefermuster

Das zuverlässigste Muster besteht aus vier Schritten. Sammeln Sie zunächst repräsentative Artefakte. Zweitens: Verwandeln Sie diese Artefakte in eine konkrete technische Diagnose. Drittens: Veröffentlichen Sie eine lokale Änderung oder einen Prototyp. Viertens wiederholen Sie den Test mit demselben Messrahmen und dokumentieren Sie die nächste Entscheidung im Klartext. In dieser Art von Arbeit sind CMake-Vorrichtungen, Profilierungs-Harnesses, kleine native Repros und Compiler-/Laufzeitnotizen normalerweise wertvoller als ein weiteres Treffen über die allgemeine Richtung.

Klare Sprache ist wichtig. Ein Käufer sollte in der Lage sein, die Ausgabe zu lesen und zu verstehen, was sich geändert hat, was weiterhin riskant ist, was warten kann und was der nächste Schritt bewirken würde. Wenn die Empfehlung nicht geplant, getestet oder einem Eigentümer zugeordnet werden kann, ist sie immer noch zu dekorativ. Dekoratives technisches Schreiben ist angenehm, aber Produktionssysteme sind nicht dafür bekannt, Angenehmes zu belohnen.

So beurteilen Sie, ob das Ergebnis geholfen hat

Für Why C++ Still Beats Rust in the KI Era sollte das Ergebnis mindestens eines von drei Dingen verbessern: Liefergeschwindigkeit, Systemvertrauen oder kommerzielle Bereitschaft. Wenn dadurch keine Verbesserung erzielt wird, hat das Team vielleicht etwas gelernt, aber der Käufer hat noch kein brauchbares Ergebnis erhalten. Diese Unterscheidung ist wichtig. Lernen ist edel. Auch ein bezahltes Engagement soll das System bewegen.

Das stärkste Ergebnis kann eine engere Roadmap, die Weigerung, einen gefährlichen Weg zu automatisieren, eine bessere Abgrenzung eines Modells, eine sauberere native Integration, ein maßvoller Beweis dafür, dass eine Neufassung noch nicht erforderlich ist, oder eine kurze Abhilfeliste sein, die die Führung tatsächlich finanzieren kann. Seriöse Ingenieurskunst ist eine Abfolge besserer Entscheidungen, kein Kostümwettbewerb um Werkzeuge.

Wie SToFU es angehen würde

SToFU würde dies zunächst als Lieferproblem und dann als Technologieproblem behandeln. Wir würden die erforderliche technische Tiefe einbringen, aber das Engagement auf Fakten gründen: dem Weg, der Grenze, dem Risiko, der Messung und der nächsten Änderung, die es wert ist, vorgenommen zu werden. Es geht nicht darum, harte Arbeit einfach klingen zu lassen. Es geht darum, den nächsten ernsthaften Schritt so deutlich zu machen, dass er ausgeführt werden kann.

Das ist der Teil, den Käufer normalerweise am meisten schätzen. Sie können überall Meinungen einholen. Was sie brauchen, ist ein Team, das das System inspizieren, die tatsächliche Einschränkung benennen, den richtigen Slice erstellen oder validieren und Artefakte zurücklassen kann, die die Verwirrung nach Ende des Anrufs verringern. In einem lauten Markt ist Klarheit keine Soft Skills. Es ist Infrastruktur.