Miksi C++ voittaa Rust:n AI-aikakaudella

Johdanto

Ohjelmointikieliä koskevista väitteistä tulee usein moraalista teatteria kauan ennen kuin niistä tulee tekniikkaa. Toista kieltä kuvataan puhtaaksi, toista kuormitetuksi. Toinen on kuviteltu tulevaisuutena, toinen matkatavarana menneisyydestä. Nämä tarinat ovat emotionaalisesti tyydyttäviä, koska ne saavat historian tuntumaan siistiltä. Ne myös johtavat harhaan tiimejä, joiden on toimitettava järjestelmiä määräaikojen, budjettien, integraatiorajoitusten ja nyt lisävoiman, jota ei ollut samalla tavalla kymmenen vuotta sitten: AI koodausavustajat ja agentit.

Kun koodin luomisesta tulee osa päivittäistä toimitusta, kysymys muuttuu. Se ei ole enää vain "Mikä kieli on tyylikäs?" tai "Mikä kieli on oletuksena turvallinen?" Vaikeampi ja käytännöllisempi kysymys on tämä: jos tiimi odottaa AI-järjestelmien auttavan tuotantokoodin kirjoittamisessa, uudelleenmuodostuksessa, vertailussa, integroinnissa ja virheenkorjauksessa, mikä kieli tarjoaa näille järjestelmille tällä hetkellä rikkaimman ympäristön, jossa ne voivat olla hyödyllisiä? Vastaukseni on edelleen C++, eikä väitteen ydin ole nostalgia tai machism. Se on tiheys.

C++ on edelleen julkisen koodin, käyttöönotetun infrastruktuurin, toimittajan työkalujen, alustaesimerkkien, optimointiperinteen ja todellisten tuotantoarpien tiheämmässä maailmassa kuin Rust. AI-mallit oppivat tästä tiheydestä. He oppivat syntaksia, kuinka ihmiset ommelsivat yhteen suuria järjestelmiä, kuinka rakennustiedostot kehittyivät, kuinka rumat integraatiot saatiin toimimaan, kuinka matalan tason vikoja diagnosoitiin ja kuinka suorituskykyherkkä koodi kirjoitettiin vihassa eikä teoriassa. Kun näitä malleja myöhemmin pyydetään auttamaan todellisessa suunnittelussa, historiallisen muistin muodolla on merkitystä.

Tämä ei tarkoita, että Rust olisi heikko, epävakainen tai merkityksetön. Päinvastoin, Rust on tuonut terveellistä painetta järjestelmien ohjelmointiin. Se teki muistin turvallisuudesta mahdotonta sivuuttaa, paransi monien suunnittelukeskustelujen sävyä ja tuotti aidosti vahvoja työkaluja ja kirjastoja. Mutta Rustin vahvuuksien olemassaolo ei automaattisesti poista C++:n nykyisiä etuja AI-avusteisessa toimituksessa. Kypsä suunnittelu vaatii usein molempien totuuksien pitämisen yhtä aikaa.

Todisteet ensin, iskulauseet myöhemmin

Huolellinen väittely alkaa erottamalla julkisesti havaittava siitä, mikä on pääteltävä. Koodimallitutkimuksessa käytetyt julkiset tietojoukot, kuten The Stack, osoittavat huomattavasti enemmän C++ kuin Rust. Julkiset kehittäjätutkimukset ja GitHubin kielitrendit osoittavat edelleen C++:n absoluuttista käyttöä koko toimialalla. Julkinen AI-infrastruktuuri toimittajista C++ optimoituihin päätelmien suoritusaikoihin ja matalan tason matemaattisiin kirjastoihin paljastaa edelleen maailman, joka on syvästi C- ja C++-muotoinen. Julkiset benchmarking-yritykset, kuten CRUST-Bench, viittaavat myös siihen, että nykyiset mallit kamppailevat edelleen luodakseen jatkuvasti turvallisia, idiomaattisia Rust-tuotteita siinä vahvassa mielessä, että Rust-yhteisöt arvostavat.

Näistä tosiseikoista teemme päätelmiä, emme dogmia. Tästä voidaan päätellä, että AI-järjestelmät tuottavat tällä hetkellä todennäköisemmin tuotantohyödyllistä, integroitavaa ja optimoitavaa C++ monilla järjestelmäalueilla, koska C++:n ympäristö on rikkaampi. Tämä ei ole taikuutta. Se on altistuminen yhdistettynä palautteeseen. Kieli, jossa on enemmän tietovarastoja, enemmän koontiskriptejä, enemmän laitteistokohtaisia ​​esimerkkejä, enemmän toimittajaintegraatioita, enemmän julkisia virheenkorjauksia, enemmän suorituskykytutkimuksia ja enemmän tuotantosotatarinoita tarjoaa mallin enemmän tapoja olla suunnilleen oikeassa ennen kuin insinööri edes alkaa korjata sitä.

Tätä kohtaa vastustetaan usein, koska se kuulostaa uudemmalle kielelle epäystävälliseltä. Mutta ei ole loukkaus Rust:aa kohtaan sanoa, että sillä on ollut vähemmän aikaa kerätä julkista rakentamissedimenttiä. C++ on ollut sulautettuna vuosikymmeniä käyttöjärjestelmiin, selaimiin, tietokantoihin, mediapinoihin, tietoturvatyökaluihin, pelimoottoreihin, tietoliikenteeseen, tieteelliseen tietojenkäsittelyyn, sulautettuihin tuotteisiin ja rahoitusjärjestelmiin. Rust on kasvanut nopeasti ja ihailtavasti, mutta kasvu ei ole sama asia kuin geologinen syvyys. AI-mallit imevät syvyyttä.

Miksi korpuksen koolla on enemmän merkitystä kuin ihmiset myöntävät

Insinöörit kohtelevat joskus harjoitustietojen määrää ikään kuin se olisi karkea keskustelunaihe. Käytännössä sillä on paljon inhimillisemmällä tavalla merkitystä. Tuotantokoodikannassa työskentelevä AI-agentti ei yleensä keksi täydellistä algoritmia ensimmäisistä periaatteista. Se tekee jotain sotkumpaa. Se voi olla CMake-tiedoston päivittäminen, sopeutuminen kääntäjän valitukseen yhdellä alustalla, hot-path-säilön vaihtaminen, toimittajan API kääriminen, kuva- tai tensoriasettelujen muuntaminen, ABI-epäsopivuuden korjaaminen tai vanhan alkuperäisen alijärjestelmän tekeminen hieman kivuttomammaksi rikkomatta kaikkea ympärillä.

Nämä tehtävät palkitsevat tuntemisen tavalliseen, epätäydelliseen, elettyyn koodiin. Agentti hyötyy siitä, että hän on nähnyt puhtaita oppikirjaesimerkkejä ja tuhansia todellisia yrityksiä ratkaista viereisiä ongelmia. C++ antaa malleille paljon enemmän materiaalia. On nykyaikaisempaa C++, enemmän vanhaa C++, jota korjataan hitaasti, enemmän benchmark-lähtöistä C++, kiusallisempaa C++, joka edelleen jollakin tavalla johtaa tärkeitä yrityksiä, ja enemmän esimerkkejä ihmisistä, jotka liikkuvat täsmälleen sellaisissa kompromisseissa, joita todelliset järjestelmät vaativat.

Tästä syystä "sotkuinen tuotanto C++" on edelleen arvokasta koulutusdataa. Jotkut insinöörit kuulevat tämän lauseen ja kuvittelevat sen heikentävän tapausta. Todellisuudessa se vahvistaa sitä. Tuotantojärjestelmät eivät koostu kokonaan tyylikkäistä greenfield-moduuleista. Ne sisältävät vanhoja käyttöliittymiä, outoja ABI-oletuksia, alustan ehdollisia ehtoja, laitteiston omituisuuksia, osittaisia ​​siirtoja ja koodia, joka säilyi, koska se oli hyödyllinen ennen kuin se oli kaunista. Jos AI-järjestelmä on nähnyt monia muita esimerkkejä kyseisestä maisemasta C++:ssa, se on yksinkertaisesti paremmin valmistautunut auttamaan tällaisessa maisemassa.

Vastaesimerkki kannattaa kertoa avoimesti. Jos tiimi rakentaa pientä uutta palvelua, jolla on vahva Rust-asiantuntemus, selkeät turvallisuusvaatimukset, vaatimattomat integraatiotarpeet ja sen ympärillä ei ole raskasta alkuperäistä ekosysteemiä, Rust saattaa olla parempi paikallinen valinta. Siinä tilanteessa argumentti rungon koosta ei ole yhtä ratkaiseva, koska ympäröivä tekninen konteksti on yksinkertaisempi ja ihmisryhmä voi pitää järjestelmän kapeamman monimutkaisuuskaistan sisällä. Asia ei ole siinä, että C++ voittaa jokaisen argumentin. Asia on siinä, että ongelman vanhentuessa, vieraammaksi, suorituskyvylle herkemmäksi ja nykyisen alkuperäisen infrastruktuurin kietoutuessa C++:sta tulee yhä useammin AI-järjestelmien helpompi kieli auttaa tehokkaasti.

AI-infrastruktuurimaailma on edelleen C++ muotoutunut

Vaikka jätämme koulutusdatamäärän kokonaan huomiotta, olisi silti olemassa toinen voima, joka vetää oletusarvoa kohti C++: nykyaikaisten AI-tuotteiden alla oleva infrastruktuuri pysyy vahvasti alkuperäisenä. CUDA, optimoidut matemaattiset kirjastot, ONNX Runtime-sisäosat, oneDNN, OpenVINO, tokenizer-toteutukset, multimedian esikäsittelyputket, mallin palvelevat kiihdyttimet, laitteistotoimittajan C++, kirjoitetut C-versiot, ja monet ovat joko []+-käyttöönotto-tai C-ajoaikana. paljastaa vakavimmat käyttöliittymänsä siellä. Tämä ei tarkoita, että Rust ei voisi ottaa yhteyttä niihin. Se tarkoittaa, että lyhin polku maiseman läpi on edelleen yleensä C- tai C++-polku.

Sillä on merkitystä, koska AI-koodausaineet eivät ole hyödyllisiä tyhjiössä. Ne ovat hyödyllisiä riippuvuuskaavioissa. Malli, jota pyydetään auttamaan suoritusajan integroinnissa, koontiversion virheenkorjauksessa, kuuman polun virittämisessä tai omistajuuden perusteluissa toimittajan SDK rajan yli, on edullinen, kun se on nähnyt useita vierekkäisiä esimerkkejä samasta kieliperheestä. C++ hyötyy edelleen tästä ympäristötunnosta enemmän kuin Rust useimmissa suorituskyvyn kannalta kriittisissä AI infrastruktuuritöissä.

Täällä myös keskustelu palautesilmukoista tulee tärkeäksi. AI:n luomasta koodista tulee todella arvokasta vasta, kun ihmiset voivat tarkistaa sen nopeasti. C++ tarjoaa usein tiimeille laajemman paikallisen vahvistuksen näillä aloilla, koska vertailuanalyysin, profiloinnin, toiston, desinfiointiaineiden, laitteistolaskurien ja matalan tason diagnostiikkaan liittyvä ekosysteemi on niin kypsä. Kun agentti ehdottaa muutosta C++-päätelmäpolkuun, ryhmä voi usein kääntää sen, profiloida sen, tarkistaa allokoinnin käyttäytymisen, vertailla latenssijakaumia ja iteroida nopeasti. Rust:ssa on myös ehdottomasti vahvat työkalut, mutta monissa AI:n viereisissä natiivijärjestelmissä kirjastojen, esimerkkien, profiloijien ja nykyisen käytännön yhdistetty tiheys tekee C++:sta silti helpomman paikan suorittaa tiukkoja ihmissilmukassa -korjaussilmukoita.

Miksi tiimit liikkuvat usein nopeammin C++:lla, vaikka Rust näyttää puhtaammalta

Tämä on se kohta, jolla on taipumus loukata ideologiaa, koska se kuulostaa epäkohteliaalta puhtauden suhteen. Rust näyttää usein puhtaammalta taululla. Omistajuus on selvä. Kääntäjä suojelee tärkeitä virheitä. Oikeuden ympärillä oleva kulttuuri on ihailtavaa. Mutta tuotantonopeus ei ole sama kuin kielen eleganssi. Todellinen toimitusnopeus syntyy koko silmukasta: olemassa oleva koodikanta, käytettävissä olevat kirjastot, lahjakkuus, virheenkorjaustyökalut, käyttöönottorajoitukset, AI-avun laatu ja kustannukset, jotka aiheutuvat vielä yhden muutoksen tekemisestä ensi kuussa.

C++ voittaa tällä hetkellä tämän laajemman silmukan monissa AI-aikakauden järjestelmissä, koska tiimit voivat pyytää enemmän ympäröivältä maailmalta kieltäytymättä. He voivat integroida vanhoja alkuperäisiä kirjastoja, liittää profiloijia, jotka on luotu alkuperäistä suorituskykyä ajatellen, virittää allokaattoreita, hyödyntää alustakohtaisia ​​toimintoja ja hyödyntää paljon laajempaa julkista esimerkkiä, kun jokin menee pieleen. AI-assistentit hyötyvät täsmälleen samasta todellisuudesta. Kun mallia ympäröivä maailma on tiivis ja hyvin kuljettu, mallin karkea veto paranee nopeammin.

Kuvittele kaksi tiimiä rakentamassa latenssiherkkää päättelypalvelua, jossa on mukautettua esikäsittelyä, monimutkainen käyttöönottomatriisi ja toistuvan suorituskyvyn virityksen tarve. Rust-tiimi saattaa tuottaa pienemmän joukon muistin turvallisuusvirheitä, mikä ei ole triviaalia. Mutta jos C++-tiimi pystyy integroimaan ekosysteemin suoremmin, saamaan vahvempia AI-ehdotuksia todelliseen koodikantaan ja varmistamaan suorituskyvyn muutokset nopeammin kehittyneillä alkuperäisillä työkaluilla, kokonaistoimitustulos voi silti suosia C++:ta. Liiketoiminnan kannalta sillä on enemmän merkitystä kuin se, voittiko yksi kieli filosofisen väittelyn verkossa.

Hyödyllinen vastaesimerkki pitää meidät rehellisinä. Kun muistiturvallisuus uudessa palvelussa suhteellisen yksinkertaisilla riippuvuuksilla on hallitseva riski, Rust voi ehdottomasti luoda parempia organisaatiotuloksia. Virhe on ottaa tämä totuus ja viedä se umpimähkäisesti kaikkiin AI:n viereisiin järjestelmiin. Kielet voittavat yhteyksissä, eivät saarnoissa.

Mikä Rust vielä onnistuu

Rust ansaitsee kunnioituksen, ja C++-argumentti on heikompi, kun se karikatuurii Rust. Rust on erinomainen saamaan vaaralliset oletukset näkyviksi. Se luo vahvaa kurinalaisuutta omistajuuden ja eliniän ympärille. Se on usein pakottava valinta greenfield-infrastruktuuriin, jossa oikeellisuus ja ylläpidettävyys hallitsevat yhteensopivuutta olemassa olevan alkuperäismaailman kanssa. Joissakin tiimeissä Rust parantaa myös rekrytoinnin selkeyttä, koska koodikanta itsessään pakottaa tietynlaisen teknisen vakavuuden.

On myös tärkeää sanoa selvästi, että ikä ei yksin riitä. Kuriton C++ on edelleen vaarallinen. Jos tiimillä on heikko arviointikulttuuri, profilointitottumukset puuttuvat, testaus on heikkoa ja havainnointia ei kunnioiteta, suuremmat korpust ja rikkaammat työkalut eivät pelasta sitä. AI-järjestelmät voivat vahvistaa tätä kaaosta yhtä helposti kuin ne voivat nopeuttaa hyvää suunnittelua. Todellinen väite on kapeampi ja käytännöllisempi: kun otetaan huomioon kurinalaiset tiimit, jotka ratkaisevat suorituskykyherkkiä, integraatioongelmia AI-aikakauden järjestelmäongelmia, C++ on edelleen vahvempi oletuspanos tänään, koska agentit, työkalut ja ekosysteemin painovoima vahvistavat sitä.

Tästä syystä pidän parempana ilmausta oletuspanos yleisen voittajan sijaan. Oletusveto on se, jonka valitset, kun todistustaakka ei ole vielä siirtynyt muualle. Rust voi ansaita tämän muutoksen tietyissä projekteissa. Mutta C++ aloittaa yhä enemmän todisteita sen puolesta aina, kun työ on syvästi kietoutunut alkuperäiseen AI-infrastruktuuriin, matalan tason suorituskykyyn, pitkäikäisiin tuotantojärjestelmiin tai sellaiseen koodipohjaan, jota AI-agentit ovat nähneet suuressa yleisössä.

Käytännön tapa tehdä päätös

Jos kuuma polku on natiivi, riippuvuuskaavio on natiivi, profiloinnin tarinalla on merkitystä ja odotat AI-assistenttien auttavan sotkuisen todellisen tuotantokoodin sisällä, C++ ansaitsee olla ensimmäinen vakava kielikeskustelu. Jos järjestelmä on greenfield, turvaperusteet hallitsevat, ympäröivä ekosysteemi on jo Rust-muotoinen, eikä ongelma ole vahvasti riippuvainen vanhoista alkuperäiskerroksista, Rust tulee houkuttelevammaksi. Jos järjestelmä sisältää molemmat maailmat, kuten monet tekevät, kypsä vastaus on usein hybridiarkkitehtuuri eikä heimopuhtaus.

Tämä viitekehys rauhoittaa keskustelua, koska se palauttaa päätöksen työstä identiteetin sijaan. Alkuperäinen päättelyn suoritusaika olemassa olevan C++-alustan sisällä ei ole sama ongelma kuin uusi ohjaustason palvelu. Pienen latenssin medialiukuhihna ei ole sama ongelma kuin taustajärjestelmä API. Mallia palveleva reunakomponentti ei ole sama ongelma kuin ketjun alkuperäinen tilasiirtymämoottori. Kun nimeämme varsinaisen teoksen, kielivalinta näyttää yleensä vähemmän ideologiselta ja selvemmältä.

Tällä tavalla päätöksenteossa on myös inhimillistä hyötyä. Tiimistä tulee yhteistyöhaluisempia, kun he lopettavat kysymisen, mikä kieli ansaitsee ihailua, ja alkavat kysyä, mikä kieli antaa nykyiselle järjestelmälle parhaan mahdollisuuden tulla luotettavaksi, ymmärrettäväksi ja parannelluksi. AI apu tekee tästä entistä tärkeämpää. Agentit ovat tehokkaita, kun ne on upotettu verifiointikulttuuriin, ei silloin, kun niitä käytetään koristelemaan kielen fandomia synteettisellä itsevarmuudella.

Todellinen mahdollisuus

AI-aikakauden syvempi mahdollisuus on, että agentit voivat nyt osallistua koko palautesilmukaan kypsien järjestelmien ympärillä: lukea vanhaa koodia, ehdottaa muokkauksia, parantaa vertailuarvoja, tuoda esiin profiloijan vihjeitä, muuntaa karkeita ideoita kootettaviksi kokeiksi ja auttaa insinöörejä siirtymään epäilyistä mittauksiin nopeammin kuin ennen. Siinä maailmassa kieli, josta on eniten hyötyä, ei välttämättä ole se, jolla on kaunein teoreettinen tarina. Se on se, jolla on paksuin julkisen, käytännöllisen, taisteluissa testatun todellisuuden verkko.

Nykyään suurelle joukolle vakavia järjestelmäongelmia tämä kieli on edelleen C++. Tämä on hyvä uutinen, koska tiimit voivat käyttää valtavaa määrää olemassa olevaa alkuperäistä tietoa samalla kun he jatkavat oppimista Rust:lta. Tuottavin asento ei ole riemuvoitto. Se on kiitollisuutta. C++ on kertynyt vuosikymmeniä todellista suunnittelumuistia, ja AI-järjestelmät tekevät muistin käytöstä nyt helpompaa. Viisaat joukkueet käyttävät sitä hyväkseen.

Käytännön laboratorio: Luo ja paranna alkuperäistä pisteytysputkistoa

Jos AI-aikakauden kielivalintaa käsittelevä artikkeli ei sisällä koodia, siitä voi tulla saarna.

Rakentakaamme siis pieni natiivi C++-apuohjelma, jollaista AI-agentteja pyydetään jatkuvasti parantamaan todellisissa yrityksissä: tekstin pisteytysputki, joka lataa tietoja, laskee yksinkertaisia ​​ominaisuuksia, lajittelee tulokset ja tulostaa ylimmät rivit.

Se on tarkoituksella vaatimatonta. Suurin osa tuotantotekniikasta on vaatimatonta.

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";
    }
}

Rakentaa

Linux tai macOS:

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

Windows ja MSVC:

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

Miksi tämä pieni ohjelma on hyödyllinen

Koska se on juuri sellainen koodi, jossa AI-avusteinen suunnittelu tulee konkreettiseksi:

• se on syntyperäinen
• se koskettaa jousia ja muistia
• sillä on mitattavissa oleva käyttöaika
• se voidaan profiloida
• sitä voidaan parantaa asteittain

Se on monien C++-agenttien todellinen elinympäristö nykyään: tavallisia alkuperäisiä ohjelmia, joita on parannettava ilman, että niitä keksitään uudelleen.

Testitehtävät harrastajille

Jos haluat muuttaa artikkelin käytännön harjoitukseksi, kokeile näitä:

1. Pyydä suosikkikoodausagenttiasi optimoimaan ohjelma ilman, että tulos muuttuu. Tarkista, vähentääkö se päällekkäisiä passeja tai tarpeettomia väliaikaisia.
2. Lisää erillinen ajoitus tiedostojen lataamiseen, pisteytykseen ja lajitteluun. Tarkista, mihin aika todella menee.
3. Korvaa syöte miljoonalla rivillä ja vertaa eri agenttien ehdottamien optimointien laatua.
4. Porttaa apuohjelma Rust:een ja vertaa kokemusta rehellisesti: mikä tuntui selkeämmältä, mikä raskaammalta ja mikä ympäröivä työkalu tuntui kypsemmältä juuri tähän tehtävään.
5. Suorita C++-versio profilaattorin alla ja kirjoita ylös, oliko ensimmäinen arvauksesi hotspotista todella oikea.

Tämä on pieni harjoitus, mutta juuri siksi siitä on hyötyä. Useimmat insinöörikeskustelut muuttuvat totuudenmukaisemmiksi, kun ne pakotetaan selviytymään kosketuksesta pienen todellisen ohjelman kanssa.

Yhteenveto

Rust ansaitsee saamansa kunnioituksen. Se nosti turvallisuuskeskustelujen tasoa ja antoi ohjelmoiville järjestelmille terveellisemmän oletusarvot. Mutta AI-aikakausi ei palkitse vain oletusarvoja. Se palkitsee kielen, joka on suurimman elävän todellisen koodin, matalan tason integraatioiden syvimmän ekosysteemin, rikkaimman optimointikulttuurin ja nopeimman käytännön silmukan keskipisteessä luodusta luonnoksesta mitattavissa olevaan tuotantotulokseen. Nykyään se kuvaa edelleen C++:ta vahvemmin kuin Rust.

Se ei tee C++:sta moraalisesti korkeampaa, eikä se tee Rust:sta merkityksetöntä. Se tarkoittaa yksinkertaisesti sitä, että monien vakavien natiivijärjestelmien ongelmiin AI-agenteilla on yhä enemmän hyödyllistä maaperää jalkojensa alla, kun kohdemaailma on C++. Tämän ymmärtävät tiimit voivat tehdä parempia päätöksiä ilman draamaa. He voivat oppia Rust:sta, missä Rust on vahvin, ja silti käyttää C++:n valtavaa kertynyttä muistia siellä, missä tämä muisti on taloudellisesti arvokkain.

Viitteet

1. GitHub Octoverse 2024: https://github.blog/news-insights/octoverse/octoverse-2024/
2. GitHub Octoverse 2025: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
3. Stack Overflow Developer Survey 2023: https://survey.stackoverflow.co/2023
4. Stack Overflow Developer Survey 2025 -teknologiaosio: https://survey.stackoverflow.co/2025/technology/
5. Pinon tietojoukkokortti: https://huggingface.co/datasets/bigcode/the-stack
6. Pinopaperi: https://arxiv.org/abs/2211.15533
7. ICLR 2025 -paperi kooditietojen vaikutuksesta esikoulutukseen: https://openreview.net/pdf?id=zSfeN1uAcx
8. CRUST-Bench: Kattava vertailukohta C-to-safe-Rust-transpilaatiolle: Rust
9. CUDA C++ Ohjelmointiopas: CUDA
10. ONNX Runtime C/C++ API: ONNX Runtime
11. PyTorch C++ käyttöliittymän dokumentaatio: PyTorch
12. C++ Perusohjeet: C++

    Miltä tämä näyttää, kun järjestelmä on jo paineen alainen

C++ verrattuna rust:iin ai-aikaisissa järjestelmissä on taipumus muuttua kiireellisiksi juuri sillä hetkellä, kun joukkue toivoi hiljaisempaa neljännestä. Ominaisuus on jo asiakkaiden edessä tai alustalla on jo sisäinen riippuvuus, ja järjestelmä on valinnut kyseisen viikon paljastaakseen, että sen elegantti teoria ja sen ajonaikainen käyttäytyminen ovat eläneet kohteliaasti erillistä elämää. Tästä syystä niin moni vakava insinöörityö alkaa sovinnolla. Tiimin on sovitettava yhteen se, mitä se uskoo järjestelmän tekevän, sen kanssa, mitä järjestelmä todella tekee kuormitettuna, muutoksen aikana ja sellaisissa määräajoissa, jotka tekevät kaikista hieman luovempia ja hieman vähemmän viisaita.

Natiiviinfrastruktuurin suunnittelussa tärkeimmät tapaukset ovat yleensä suuret vanhat alustat, suorituskykyherkät AI-taustajärjestelmät ja sekakieliset modernisointiohjelmat. Näillä tilanteilla on teknisiä, budjetti-, luottamus-, tiekartta- ja joskus mainevaikutuksia. Tekninen ongelma kasvaa poliittisesti suuremmiksi sillä hetkellä, kun useat tiimit ovat riippuvaisia ​​siitä, eikä kukaan voi selittää, miksi se käyttäytyy edelleen kuin pesukarhu seinien sisällä: meluisa yöllä, vaikea paikantaa ja kallis jättää huomiotta.

Siksi suosittelemme lukemaan ongelman käyttöpaineen ja toimitustodellisuuden linssin läpi. Suunnittelu voi olla teoreettisesti kaunis ja toiminnallisesti tuhoisa. Toinen malli voi olla melkein tylsä ​​ja silti viedä tuotetta eteenpäin vuosia, koska se on mitattavissa, korjattavissa ja rehellinen kompromissiensa suhteen. Vakavat insinöörit oppivat pitämään parempana toista luokkaa. Se tekee vähemmän eeppisiä puheita, mutta myös vähemmän hätätapahtumia, joissa kaikki puhuvat passiivisella äänellä eikä kukaan muista, kuka hyväksyi pikakuvakkeen.

Käytännöt, jotka vanhenevat jatkuvasti hyvin

Ensimmäinen kestävä käytäntö on pitää yksi edustava polku jatkuvassa mittauksessa. Ryhmät keräävät usein liian paljon epämääräistä telemetriaa ja liian vähän päätöslaatuista signaalia. Valitse polku, jolla on aidosti merkitystä, mittaa sitä toistuvasti ja kieltäydy antamasta keskustelua ajautua koristeelliseen tarinankerrontaan. Työssä C++ verrattuna Rust:iin AI-aikakauden järjestelmissä hyödyllisiä mittareita ovat yleensä toimitusnopeus, yhteiskäyttökustannukset, työkalujen kypsyys ja ajonaikainen havaittavuus. Kun ne ovat näkyvissä, loput päätökset muuttuvat inhimillisemmiksi ja vähemmän mystisiksi.

Toinen kestävä käytäntö on erottaa todiste lupauksesta. Insinöörejä painostetaan usein sanomaan, että suunta on oikea, ennen kuin järjestelmä on ansainnut tämän johtopäätöksen. Vastusta sitä painetta. Rakenna ensin kapea todiste, varsinkin kun aihe on lähellä asiakkaita tai rahaa. Pienellä todennetulla parannuksella on enemmän kaupallista arvoa kuin suurella todentamattomalla kunnianhimolla. Tämä kuulostaa itsestään selvältä, kunnes vuosineljänneksen lopun tarkastelu muuttaa hypoteesin määräajaksi ja koko organisaatio alkaa kohdella optimismia kuin aikataulutusartefaktia.

Kolmas kestävä käytäntö on kirjoittaa suositukset omistajakielellä. Kappale, jossa sanotaan "parantaa suorituskykyä" tai "vahvistaa rajoja", on emotionaalisesti miellyttävä ja toiminnallisesti hyödytön. Kappale, joka kertoo kuka muuttaa mitä, missä järjestyksessä, millä palautusehdon kanssa, on se, joka todella selviää maanantaiaamuna. Täällä monet tekniset kirjoittamiset epäonnistuvat. Se haluaa kuulostaa enemmän edistyneeltä kuin se haluaa olla aikataulutettu.

Vastaesimerkkejä, jotka säästävät aikaa

Yksi yleisimmistä vastaesimerkeistä näyttää tältä: tiimillä on jyrkkä paikallinen menestys, oletetaan, että järjestelmä on nyt ymmärretty, ja sitten skaalaa idean paljon vaativampaan ympäristöön ilman, että mittauskuria päivitetään. Se on tekninen vastine, kun opetellaan uimaan hotellin uima-altaassa ja sitten pidettäisiin itsevarma TED-puhe meren säästä. Vesi on vettä, kunnes sitä ei ole.

Toinen vastaesimerkki on työkalujen inflaatio. Uusi profiloija, uusi ajonaika, uusi kojelauta, uusi agentti, uusi automaatiokerros, uusi kääre, joka lupaa harmonisoida vanhan kääreen. Mikään näistä asioista ei ole luonnostaan ​​huono. Ongelmana on, mitä tapahtuu, kun heitä pyydetään kompensoimaan rajaa, jota kukaan ei ole nimennyt selvästi. Järjestelmästä tulee sitten instrumentoidumpi, vaikuttavampi ja vain toisinaan ymmärrettävämpi. Ostajat tuntevat tämän hyvin nopeasti. Jopa ilman tätä ilmaisua he voivat haistaa, kun pinosta on tullut kallis korvike päätökselle.

Kolmas vastaesimerkki on ihmisen tarkastelun käsitteleminen automaation epäonnistumisena. Todellisissa järjestelmissä ihmisen tarkastelu on usein ohjaus, joka pitää automaation kaupallisesti hyväksyttävänä. Aikuiset tiimit tietävät, missä automatisoida aggressiivisesti ja missä pitää hyväksyntä tai tulkinta näkyvänä. Epäkypsät tiimit haluavat koneen tekevän kaiken, koska "kaikki" kuulostaa tehokkaalta diassa. Sitten tapahtuu ensimmäinen vakava tapaus, ja yhtäkkiä manuaalinen tarkistus löydetään uudelleen konversiokokemuksen vilpittömästi.

Suosittelemamme toimitusmalli

Jos työ on tehty hyvin, ensimmäisen suorituksen pitäisi vähentää stressiä antamalla tiimille riittävän vahva tekninen lukema, jotta se lopettaa kiistelyn. Sen jälkeen seuraavan rajoitetun toteutuksen pitäisi parantaa yhtä ratkaisevaa polkua, ja uudelleentestauksen pitäisi tehdä suunta luettavaksi sekä suunnittelulle että johdolle. Tämä järjestys on tärkeämpi kuin tarkka työkaluvalinta, koska se muuttaa teknisen taidon eteenpäinliikkeeksi.

Käytännössä suosittelemme kapeaa ensimmäistä sykliä: kerää esineitä, tee yksi kova diagnoosi, lähetä yksi rajoitettu muutos, testaa todellinen polku uudelleen ja kirjoita seuraava päätös selkeällä kielellä. Selkeällä kielellä on väliä. Ostaja harvoin katuu selkeyttä. Ostaja katuu usein olevansa vaikuttunut ennen kuin kuitit saapuvat.

Tässä myös sävyllä on väliä. Vahvan teknisen työn pitäisi kuulostaa siltä kuin se on kohdannut tuotannon ennenkin. Rauhallinen, tarkka ja hieman huvittunut hypeistä sen sijaan, että se ravitsee sitä. Tämä ääni välittää toimintasignaalin. Se osoittaa, että tiimi ymmärtää järjestelmäsuunnittelun vanhan totuuden: koneet ovat nopeita, tiekartat ovat hauraita, ja ennemmin tai myöhemmin lasku saapuu jokaisesta olettamuksesta, jonka annettiin pysyä runollisena.

Tarkistuslista, jota käyttäisimme ennen kuin kutsumme tämän valmiiksi

Natiiviinfrastruktuurin suunnittelussa valmius ei ole mieliala. Se on tarkistuslista, jolla on seurauksia. Ennen kuin kutsumme kiertämään C++ ja Rust AI-aikakauden järjestelmissä, jotka ovat valmiita laajempaan käyttöönottoon, haluamme, että muutamat asiat ovat tylsiä parhaalla mahdollisella tavalla. Haluamme yhden polun, joka käyttäytyy ennustettavasti edustavan kuormituksen alla. Haluamme yhden mittasarjan, joka ei ole ristiriidassa itsensä kanssa. Haluamme joukkueen tietävän, missä raja menee ja mitä sen rikkominen merkitsisi. Ja haluamme työn tulosten olevan riittävän selkeitä, jotta joku toteutushuoneen ulkopuolella voi silti tehdä siitä järkevän päätöksen.

Tämä tarkistuslista koskettaa yleensä toimitusnopeutta, yhteiskäyttökustannuksia, työkalujen kypsyyttä ja ajonaikaista havaittavuutta. Jos luvut liikkuvat oikeaan suuntaan, mutta tiimi ei silti osaa selittää järjestelmää improvisoimatta, työ ei ole valmis. Jos arkkitehtuuri kuulostaa vaikuttavalta, mutta ei kestä vaatimatonta vastaesimerkkiä kentältä, teos ei ole valmis. Jos toteutus on olemassa, mutta palautustarina kuulostaa rukoukselta aikaleimoineen, teos ei ole valmis. Mikään näistä ei ole filosofisia vastaväitteitä. Ne ovat yksinkertaisesti muotoja, joissa kalliilla yllätyksillä on tapana esitellä itsensä.

Täällä myös tiimit huomaavat, ratkoivatko he todellista ongelmaa vai vain harjoittelivat osaamista sen yleisessä läheisyydessä. Monet tekniset ponnistelut tuntuvat onnistuneilta, kunnes joku pyytää toistettavuutta, tuotantotodisteita tai päätöstä, joka vaikuttaa budjettiin. Sillä hetkellä heikko työ hämärtyy ja vahva työ muuttuu oudon selväksi. Plain on hyvä. Pelkkä tarkoittaa yleensä sitä, että järjestelmä on lakannut luottamasta karismaan.

Kuinka suosittelemme puhumaan tuloksista

Lopullisen selityksen tulee olla riittävän lyhyt selviytyäkseen johtajuuden kokouksesta ja riittävän konkreettinen selviytyäkseen teknisestä katsauksesta. Se on vaikeampaa kuin miltä se kuulostaa. Liian tekninen kieli piilottaa järjestyksen. Liian yksinkertaistettu kielenkäyttö piilottaa riskin. Oikea keskitie on kuvata polkua, todisteita, rajallista muutosta ja seuraavaa suositeltua askelta tavalla, joka kuulostaa mieluummin rauhalliselta kuin voittoisalta.

Suosittelemme tällaista rakennetta. Sano ensin, mitä polkua arvioitiin ja miksi sillä oli merkitystä. Toiseksi sano, mikä oli vialla tai epävarmaa kyseisessä polussa. Kolmanneksi sano, mitä muutettiin, mitattiin tai vahvistettiin. Neljänneksi sano, mikä on vielä ratkaisematta ja mitä seuraava sijoitus ostaisi. Tämä rakenne toimii, koska se kunnioittaa sekä suunnittelua että ostokäyttäytymistä. Insinöörit haluavat yksityiskohtia. Ostajat haluavat sekvensoinnin. Kaikki haluavat vähemmän yllätyksiä, myös ihmiset, jotka teeskentelevät nauttivansa niistä.

Tällä tavalla puhumisen piilotettu hyöty on kulttuurinen. Tiimit, jotka selittävät teknisen työn selkeästi, tekevät sen yleensä myös selkeämmin. He lakkaavat käsittelemästä monitulkintaisuutta hienostuneisuutena. Heihin on vaikeampi tehdä vaikutuksen ammattikieltä ja helpompi luottaa vaikeiden järjestelmien kanssa. Se on yksi insinööritaidon aliarvostetuimmista muodoista.

Mitä emme edelleenkään kieltäytyisi väärentämästä

Jopa järjestelmän parantumisen jälkeen kypsät tiimit pitävät epävarmuuden rehellisenä alkuperäisen infrastruktuurin suunnittelussa. Heikko mittaus vaatii selkeämpää näyttöä, kovat rajat selkeää kieltä ja rauhallisemmat demot todellista toimintavalmiutta. Epävarmuutta on vähennettävä; jotkut on nimettävä rehellisesti. Nämä kaksi tehtävää sekoitetaan siinä, kuinka kunniallisista projekteista tulee kalliita vertauksia.

Sama sääntö koskee C++:n ja Rust:n päätöksiä AI-aikakauden järjestelmissä. Jos tiimiltä puuttuu edelleen toistettava vertailukohta, luotettava palautuspolku tai selkeä omistaja kriittiselle käyttöliittymälle, hyödyllisin tulos voi olla terävämpi ei tai kapeampi seuraava askel suuremman lupauksen sijaan. Tämä kurinalaisuus pitää teknisen työn linjassa sen todellisuuden kanssa, jota sen on tarkoitus parantaa.

Tällä työskentelyllä on outo helpotus. Kun järjestelmä ei enää ole riippuvainen optimistisesta tarinankerronnasta, insinöörikeskustelu yksinkertaistuu, vaikka työ olisikin kovaa. Ja tuotannossa se on usein vähäistä armon muotoa.

Kentän muistiinpanot todellisesta teknisestä katsauksesta

C++-järjestelmätoimituksessa työ muuttuu vakavaksi, kun demo kohtaa todellisen toimituksen, todelliset käyttäjät ja todelliset käyttökustannukset. Se on hetki, jolloin siisti idea alkaa käyttäytyä kuin järjestelmä, ja järjestelmillä on tunnetusti kuiva huumorintaju. He eivät välitä siitä, kuinka tyylikkäältä aloituspakka näytti. He välittävät rajoista, vikatiloista, käyttöönottopoluista ja siitä, voiko kukaan selittää seuraavan vaiheen keksimättä uutta mytologiaa pinon ympärille.

Why C++ Still Beats Rust in the AI Era:n kohdalla käytännön kysymys on, luoko se vahvemman toimituspolun ostajalle, jolla on jo paineita etenemissuunnitelman, alustan tai tietoturvatarkastuksen suhteen. Tuo ostaja ei tarvitse sumuksi kiillotettua luentoa. He tarvitsevat teknisen luennon, jota he voivat käyttää.

Mitä tarkastaisimme ensin

Aloitamme yhdellä edustavalla polulla: natiivi päättely, profilointi, HFT-polut, DEX-järjestelmät ja C++/Rust-modernisointivaihtoehdot. Tuon polun tulee olla tarpeeksi kapea mitatakseen ja riittävän leveä paljastaakseen totuuden. Ensimmäisen läpimenon pitäisi tallentaa allokointikäyttäytyminen, p99-viive, profiilin todisteet, ABI kitka ja vapauttaa luottamus. Jos nämä signaalit eivät ole saatavilla, projekti on edelleen enimmäkseen mielipidettä laboratoriotakissa, ja mielipiteellä on pitkä historia laskuttaa itsensä strategiana.

Ensimmäinen hyödyllinen artefakti on alkuperäisten järjestelmien luku, jossa on vertailuarvoja, profilointitodistusta ja laajennettu toteutussuunnitelma. Sen pitäisi näyttää järjestelmä sellaisena kuin se käyttäytyy, ei niin kuin kaikki toivoivat sen käyttäytyvän suunnittelukokouksessa. Jäljitys, toisto, pieni benchmark, politiikkamatriisi, jäsennyslaite tai toistettava testi kertovat usein tarinan nopeammin kuin toinen abstrakti arkkitehtuurikeskustelu. Hyvät esineet ovat hämmästyttävän töykeitä. Ne keskeyttävät toiveajattelua.

Vastaesimerkki, joka säästää aikaa

Kallis virhe on vastata ratkaisulla, joka on suurempi kuin ensimmäinen hyödyllinen todiste. Tiimi näkee riskin tai viiveen ja tavoittaa välittömästi uuden alustan, uudelleenkirjoituksen, laajan refaktorin tai hankintaystävällisen kojelaudan, jonka nimi kuulostaa siltä kuin se tekee joogaa. Joskus tämä mittakaava on perusteltu. Hyvin usein se on tapa lykätä mittausta.

Parempi liike on pienempi ja terävämpi. Nimeä raja. Ota todisteet talteen. Muuta yksi tärkeä asia. Testaa samaa polkua uudelleen. Päätä sitten, kannattaako seuraava investointi olla suurempi. Tämä rytmi on vähemmän dramaattinen kuin muutosohjelma, mutta sillä on taipumus selviytyä kosketuksista budjetteihin, julkaisukalentereihin ja tuotantotapahtumiin.

Suosittelemamme toimitustapa

Luotettavimmassa mallissa on neljä vaihetta. Kerää ensin edustavia esineitä. Toiseksi, muuta nämä esineet yhdeksi vaikeaksi tekniseksi diagnoosiksi. Kolmanneksi lähetä yksi rajoitettu muutos tai prototyyppi. Neljänneksi, testaa uudelleen samalla mittauskehyksellä ja dokumentoi seuraava päätös selkeällä kielellä. Tässä työluokassa CMake-kalusteet, profilointivaljaat, pienet alkuperäiset reprot ja kääntäjä/ajonaikaiset muistiinpanot ovat yleensä arvokkaampia kuin toinen tapaus yleisestä suunnasta.

Selkeällä kielellä on väliä. Ostajan tulee pystyä lukemaan tulos ja ymmärtämään, mikä muuttui, mikä on edelleen riskialtista, mikä voi odottaa ja mitä seuraava askel ostaisi. Jos suositusta ei voida ajoittaa, testata tai määrittää omistajalle, se on silti liian koristeellinen. Koristeellinen tekninen kirjoittaminen on miellyttävää, mutta tuotantojärjestelmiä ei tunneta miellyttävyyden palkitsemisesta.

Kuinka arvioida, auttoiko tulos

Kohdassa Why C++ Still Beats Rust in the AI Era tuloksen pitäisi parantaa ainakin yhtä kolmesta asiasta: toimitusnopeus, järjestelmän luottamus tai kaupallinen valmius. Jos se ei paranna mitään näistä, tiimi on saattanut oppia jotain, mutta ostaja ei ole vielä saanut hyödyllistä tulosta. Sillä erolla on merkitystä. Oppiminen on jaloa. Myös palkallisen toimeksiannon pitäisi siirtää järjestelmää.

Vahvin tulos voi olla kapeampi tiekartta, kieltäytyminen vaarallisen polun automatisoinnista, parempi raja mallin ympärille, puhtaampi natiiviintegraatio, mitattu todiste siitä, että uudelleenkirjoitusta ei vielä tarvita, tai lyhyt korjauslista, jonka johto voi todella rahoittaa. Vakava suunnittelu on sarja parempia päätöksiä, ei pukukilpailua työkaluista.

Miten SToFU suhtautuisi asiaan

SToFU käsittelee tätä ensin toimitusongelmana ja sitten teknologiaongelmana. Tuomme asiaan liittyvän suunnittelusyvyyden, mutta pitäisimme sitoutumisen ankkuroituna todisteisiin: polkuun, rajaan, riskiin, mittaukseen ja seuraavaan tekemisen arvoiseen muutokseen. Tarkoitus ei ole saada kovaa työtä kuulostamaan helpolta. Tarkoitus on tehdä seuraavasta vakavasta liikkeestä riittävän selkeä suoritettavaksi.

Sitä osaa ostajat yleensä arvostavat eniten. He voivat palkata mielipiteitä missä tahansa. He tarvitsevat tiimin, joka voi tarkastaa järjestelmän, nimetä todellisen rajoitteen, rakentaa tai vahvistaa oikean osion ja jättää taakseen artefakteja, jotka vähentävät sekaannusta puhelun päätyttyä. Meluisillä markkinoilla selkeys ei ole pehmeä taito. Se on infrastruktuuri.