C++, Rust, og høyfrekvent handel: der deterministisk ventetid bestemmer argumentet

Introduksjon

Programmeringsspråkdebatter tolereres vanligvis fordi de fleste systemer har råd til litt teater. En tjeneste er litt ineffektiv, en kø blir bredere enn den burde, en politikk for å prøve på nytt gjør noe moralsk tvilsomt, og alle fortsetter å bevege seg fordi produktet fortsatt fungerer, inntektene lander fortsatt, og latensdiagrammet er stygt på en overlevende måte. Lag kan bruke flere uker på å krangle om renhet fordi systemet i seg selv er høflig nok til ikke å gi dem et smuss umiddelbart.

Høyfrekvent handel er mindre sentimental. Det bryr seg ikke om hvilket språk som vant internett dette kvartalet, hvilket konferanseforedrag som hadde de reneste lysbildene, eller hvilket omskrivingsinitiativ som fikk folk til å føle at fremtiden endelig var kommet. Det bryr seg om markedsdata blir stat, stat blir en beslutning, og beslutningen blir en ordre før vinduet lukkes. I slike omgivelser blir elegante meninger som ikke kan overleve målinger, raskt og vanligvis uten forvarsel ranet.

Det er derfor spørsmålet om C++ og Rust i HFT er interessant. Ikke fordi det ene språket er hellig og det andre er uredelig, men fordi HFT er et av de sjeldne domenene som tvinger hele argumentet til å utbetale faktisk systematferd. Den varme banen holder enten formen under press, eller så gjør den det ikke. Halelatens forblir enten disiplinert eller så gjør den det ikke. Replay forteller enten sannheten eller ikke. Arkitektur er ikke en personlighetstest der. Det er en faktura med vedlagt klokke.

Og HFT er uvanlig ærlig om hvor regningen kommer fra. Det er ikke bare selve matchings- eller utførelsesvinduet. Kostnadene akkumuleres i feedparsing, bokvedlikehold, serialisering, tverrkjernekommunikasjon, jitter under belastning og alle de små "sannsynligvis fine" beslutningene som blir offentlig ydmykelse når systemet blir utsatt for ekte spillestedtrafikk. Markedet har en grusom gave til å konvertere vagt ingeniørspråk til eksakte tap.

Dette er også grunnen til at svaret ikke er "C++ for alltid" eller "skriv om alt i Rust fordi sikkerhet er bra og frykt er en forretningsmodell." Det mer ærlige svaret er smalere og derfor mer nyttig. C++ dominerer fortsatt de hotteste HFT-banene fordi verden rundt verktøy, fôrhåndtering, minnekontroll, profilering og maskinvaretilstøtende praksis forblir ekstremt C++ formet. Rust er genuint nyttig rundt den kjernen, og noen ganger i nøye utvalgte deler av den, men det sletter ikke det grunnleggende faktum at handel med lav latens straffer abstraksjonsfeil raskere enn de fleste lag kan gi nytt navn til initiativet.

Så den rette samtalen handler ikke om identitet. Det handler om systemgrenser. Hvilke deler av stabelen trenger brutal kontroll over minne, layout, køer, affinitet og ledningsadferd? Hvilke deler drar mest nytte av sterkere korrekthetsbegrensninger og sikrere standardinnstillinger? Hvilke deler fortjener hybridbehandling i stedet for stammerenhet? Disse spørsmålene er langt mindre glamorøse enn språkprekener, men de er også spørsmålene som overlever kontakt med produksjon og spørsmålene som lar team samarbeide rundt bevis i stedet for slagord.

Hvorfor HFT får dårlig teknisk filosofi til å se dyr ut

HFT er uvanlig flink til å avsløre en kjent ingeniørløgn: løgnen om at gjennomsnittlig oppførsel er nok. I mange vanlige produkter kan et system forbli respektabelt mens det skjuler sporadisk kaos bak gjennomstrømming, gjenforsøk eller brukerens tålmodighet. I HFT er gjennomsnittlig ventetid interessant, men haleadferd er ofte den delen som faktisk ydmyker deg. Et system som ser raskt ut til det rykker til feil tid, er ikke et raskt system i noen kommersielt meningsfylt forstand. Det er et selvtillitstriks med en benchmark vedlagt.

Det er derfor HFT ingeniører blir allergiske mot upresise abstraksjoner. De lærer at én ekstra tildeling på den varme banen ikke er «bare én tildeling». Det er en mulig kilde til jitter. Ett køhopp er ikke «bare ett køhopp». Det er et annet sted hvor tiden blir lagret, koordinasjonen utvides og synligheten blir dårligere. En cache-fiendtlig struktur er ikke bare en estetisk lyte. Det er en løpende skatt på hver markedshendelse som går gjennom systemet. Multipliser det med reelt fôrvolum, og plutselig blir et designvalg fra et lysbildekort en gjenganger i budsjettet for skuffelse.

Det grusomme med domenet er at det også straffer delforklaringer. Et team kan identifisere en åpenbar latenskilde og fortsatt savne den virkelige lovbryteren fordi kjeden er kumulativ. En beslutning om minnelayout utvider cache-miss-profilen. Det utvider køvinduet. Det endrer hvordan systemet oppfører seg under eksplodert trafikk. Det endrer rekkefølgen som "sjelden" grenadferd vises i. Så går noen inn i obduksjonen og sier at problemet var "nettverksstøy", som er ingeniørkode for "vi er ikke ferdige med å fortelle sannheten ennå."

Rust går inn i denne samtalen med legitim kraft fordi minnesikkerhet er viktig, samtidighet er viktig, og systemkode fortjener bedre standardverdier enn "vær forsiktig mens du sjonglerer med kniver over en grop." Den delen er sann. Men HFT belønner ikke sannhet isolert. Det belønner kombinert sannhet. Sikkerhet er viktig, ja. Det samme gjør modne fôrbehandlere, stabile ABI grenser, replay-verktøy, profildrevet iterasjon, moden utvekslingsintegrasjonskultur og muligheten til å inspisere nøyaktig hva maskinen gjør når markedet er uvennlig. C++ kommer fortsatt med mer av den omkringliggende infrastrukturen i de fleste HFT-miljøer.

Dette er en grunn til at kjøpere og ingeniørledere bør motstå renhetsfortellinger. Et språk kan være utmerket i en smal dimensjon og fortsatt være feil standard for den mest tidsfølsomme delen av en stabel hvis det omkringliggende økosystemet, verktøyene og teamopplevelsen ikke støtter den faktiske leveringsveien. HFT er hvor vakre lokale sannheter går for å lære at hele veien fortsatt betyr mer. Stakken bryr seg ikke om at en påstand var moralsk elegant hvis det resulterende systemet er operasjonelt usammenhengende.

Det er også her teamøkologi betyr mer enn folk innrømmer. Et samarbeidsteam med en disiplinert gjenspillsele, et delt latenstidsvokabular og kjedelig gode profileringsvaner vil vanligvis overgå et mer fasjonabelt lag som stadig forvirrer smaken på bevis. HFT belønner sterk teknisk kultur mer pålitelig enn den belønner fasjonabel migrasjonsenergi.

Stakken er ikke én ting, så språkvalget bør ikke late som noe annet

En av de dummeste feilene i seriøst systemarbeid er å snakke om "HFT-stakken" som om det var en enkelt teknisk organisme med ett foretrukket språk. Det er det ikke. Det er en samling av stier med svært forskjellige trykk og feilkostnader.

Banen for inntak av markedsdata har ett temperament. Oppdateringsbanen for ordreboken har en annen. Strategilogikk kan være numerisk tett, men strukturelt smal. Risikosjekker er ofte latenssensitive, men også korrekthetssensitive på en kjedelig, voksen, juridisk konsekvensmessig måte. Simulering og replay-infrastruktur kan sette pris på determinisme og introspeksjon over rå nanosekunders forfengelighet. Verktøy på kontrollplan, distribusjonshjelpere og operatøroverflater bryr seg mye mer om pålitelighet, vedlikehold og integreringshygiene enn de bryr seg om å barbere fem mikrosekunder fra en bane ingen kunde noen gang vil se.

Det er også menneskelige operasjonelle forskjeller mellom disse lagene. Noen stier endres daglig av et bredere team. Noen blir berørt sjelden og kun under tilsyn. Noen komponenter trenger aggressiv sporbarhet fordi overholdelse eller revisjon til slutt vil stille vanskelige spørsmål. Noen trenger bare tett avgrenset ytelse og utmerket reprise. Å behandle disse som én beslutning er hvordan organisasjoner ender opp med enten å overmodernisere rolige komponenter eller understyre farlige.

Dette er viktig fordi det ofte er der en fornuftig C++ og Rust samtale begynner. C++ forblir sterkest når banen er brutalt varm, maskinvarebevisst, integreringstung og allerede omgitt av år med innfødt operasjonspraksis. Rust blir mer attraktiv når banen fortsatt er viktig, men den økonomiske verdien av sterkere mislighold, klarere eierskap og smalere eksponering for minnerisiko oppveier kostnadene ved økosystemfriksjon.

I praksis fører det ofte til hybride utfall. De heteste fôrhåndterings- og gatewaybanene forblir i C++. Replay-verktøy, konfigurasjonsvalidering, visse hjelpere på risikosiden, meldingsnormaliseringsverktøy, revisjonsverktøy eller interne operatørvendte komponenter kan være utmerkede Rust-kandidater. Dette er ikke ubesluttsomhet. Det er arkitektonisk voksenliv. Systemet blir behandlet som et sett med reelle grenser i stedet for som et språkfandom med et datasenter.

Og det er her mange omskrivingsforslag endelig blir ærlige. Når et team kartlegger stabelen bane for bane, har fantasien om et enkelt universelt svar en tendens til å kollapse. Den kollapsen er sunt. Det gir organisasjonen tillatelse til å optimalisere for bevis, vedlikeholdbarhet, operasjonell tillit og leveringsrytme i stedet for for den følelsesmessige komforten ved å ha et enkelt slagord.

Der C++ fortsatt eier de hotteste stiene

C++ beholder sin plass i HFT av grunner som er mindre mystiske enn utenforstående noen ganger forestiller seg. Den første grunnen er minne- og layoutkontroll. HFT hot paths bryr seg om hvilke data som lever sammen, hvordan strukturer oppfører seg i cache, hvordan eierskap dukker opp under belastning, og om systemet kan forbli allokeringsdisiplinert når markedet slutter å være høflig. C++ gir fortsatt ingeniører uvanlig direkte innflytelse over disse valgene, og det gjør det i et økosystem som allerede har brukt flere tiår på å lære hvilke "små" kostnader som er hemmelig store.

Den andre grunnen er verktøytetthet. C++ i HFT betyr ikke bare et språk. Det betyr kompilatorer, desinfiseringsmidler, flammegrafer, C++, VTune, replay-seler, utvekslingsadaptere, folklore i kø, allokatorekspertise og en enorm mengde prestasjonskrigshistorier samlet under økonomisk press. Lag starter ikke fra null der. De arver en dyp operasjonell kultur, og den kulturen er viktig fordi HFT belønner målt iterasjon langt mer enn retorisk renslighet.

Den tredje grunnen er integrasjonstyngdekraften. Utvekslinger, native nettverksbaner, pakkefangstverktøy, optimalisering ved kjernen, FPGA-tilstøtende infrastruktur og hele økosystemet med lav latens er fortsatt svært komfortable i en C- og C++-verden. Rust kan samhandle med den verden, og noen ganger veldig effektivt, men "kan samhandle med" er ikke det samme som "er veien til minst friksjon gjennom hele systemet." I alvorlige HFT er friksjon ikke en følelsesmessig ulempe. Det er en mulig latensavgift, en feilsøkingsavgift og en leveringsavgift på samme tid.

Det er også en mer subtil grunn som betyr mer i KI-tiden: C++ har ganske enkelt mer operativt minne tilgjengelig rundt dette arbeidet. KI kodesystemer, kodesøk, offentlige eksempler, leverandørbiter, optimizer-folklore og feilsøkingsstier er tettere rundt C++ i systemer med lav latens enn rundt Rust. Det gjør ikke C++ edlere. Det gjør det lettere for mennesker og KI verktøy å samarbeide inne i stygge ekte kodebaser hvis sjarm utløp for mange år siden.

En annen fordel er at mange HFT-team allerede har gjort C++ til institusjonelt muskelminne. De vet hvordan de skal profilere det under spillestedpress. De vet hvordan de skal fjerne tildelinger fra mistenkelige baner. De vet hvordan «raskt nok i mikrobenchmark» høres ut når det er i ferd med å bli falskt i produksjonen. Den levde kunnskapen er ikke romantisk, men den er driftsmessig verdifull. Et team som allerede vet hvordan de skal holde C++ ærlig bør ikke kaste det lett bort bare fordi et nyere språk føles renere isolert.

Dette er grunnen til at C++ forblir sterkest, ikke bare som syntaks, men som et omgivende håndverkssystem. Når du legger til interne biblioteker, testseler, fangeverktøy, trådtilhørighetsvaner, frigjør muskler og diagnostiseringsarbeidsflyter, sammenligner du ikke lenger ett språk med et annet i et vakuum. Du sammenligner ett helt leveringsøkosystem med et annet. I HFT slår økosystemer ofte idealer.

Hvor Rust faktisk hjelper i stedet for å utføre moral

Rust hjelper de fleste når det løser et reelt problem i stedet for å fungere som personlighetstilbehør for arkitekturdiagrammer. I HFT vises de sterkeste Rust-brukstilfellene ofte rundt den varme kjernen i stedet for i det absolutte sentrum av den.

Rust er nyttig for komponenter der korrekthetsfeil er dyre, men latensbudsjettet ikke måles med et mikroskop. Meldingsvalideringslag, konfigurasjons- og distribusjonsverktøy, visse protokollnormaliseringsbaner, kontrolltjenester, administrative verktøy, offline-analysatorer og interne operatørverktøy kan dra nytte av språkets skjevhet mot eksplisitthet. Poenget der er ikke å se moderne ut. Poenget er å redusere klassen av dumme, repeterende, strukturelt unngåelige feil som trekker oppmerksomheten fra viktigere arbeid.

Rust kan også hjelpe til med nøye utvalgte nesten varme komponenter når teamet har riktig ekspertise og grensen er ærlig. En parser med lav latens, en avgrenset tilstandsmaskin eller et stykke deterministisk infrastruktur kan være en solid Rust-kandidat hvis teamet kan holde FFI og allokeringshistorien under kontroll, og hvis den omkringliggende økosystembyrden er forstått på forhånd i stedet for å bli oppdaget klokken 2:40 om morgenen under en utrulling.

Det er også ofte til hjelp i arbeidet rundt arbeidet. Capture-prosessorer, frakoblede bokrespillere, revisjonshjelpere, distribusjonsvalidering eller strategitilstøtende infrastruktur drar nytte av strengere eierskap og klarere grensesnitt selv når de ikke er den absolutte nanosekunders slagmark. Disse delene er viktige fordi de bestemmer hvor raskt teamet kan diagnostisere hendelser, reprodusere anomalier og gå trygt fra mistanke til bekreftet forståelse.

Men det er akkurat her lagene trenger disiplin. Rust er ikke verdifull når den slippes inn i midten av en naturlig handelsstabel som en trosbasert renovering. Det er verdifullt når grensen er ren, målebanen er åpenbar, og driftskostnadene for integrasjonen er lavere enn sikkerhets- eller vedlikeholdsgevinsten den skaper. Ellers blir prosjektet en vakker case-studie i hvordan man kan bruke seriøs ingeniørtid på å flytte usikkerhet sidelengs.

Det er det virkelige antimønsteret å unngå: å ikke bruke Rust, men å bruke det til å skjule fraværet av arkitektonisk klarhet. Hvis teamet ikke kan forklare hvor eierskap begynner, hvor latens måles, hvor buffere krysser hverandre og hvor gjenoppretting skjer under stress, vil ikke endring av språk redde designet. Det vil bare gjøre feilen mer tospråklig.

Grensen betyr mer enn prekenen

En vanlig feil i C++ versus Rust diskusjoner er å anta at bruk av Rust automatisk fjerner fare. Det gjør det ikke. Det endrer hvor faren sitter. I HFT er dette grensespørsmålet spesielt viktig fordi varme stier sjelden ender ved språklinjen. De ender ved nettverksgrenser, køgrenser, planleggingsgrenser, FFI grenser og grenser for dataoppsett.

Hvis en Rust-komponent må krysse inn i en C++-utvekslingsadapter, snakke med en innfødt kø, levere data til en strategimotor med stramme layoutforutsetninger, eller opprettholde deterministisk oppførsel på tvers av grenseoverganger, så er ikke det virkelige ingeniørarbeidet "vi brukte Rust." Det virkelige arbeidet er hvor nøye sømmen ble definert og verifisert. Usikker oppførsel kan fortsatt komme gjennom ABI mismatch, eierskapsforvirring, skjulte kopier, køfeil eller tidsoverraskelser. Språket alene er ikke din styringsmodell. Grensen er.

Dette er grunnen til at modne lag snakker om en smal varm sti og en smal utrygg overflate. De er ikke avhengige av slagord som "minnesikkerhet som standard" for å løse det som fundamentalt er et systemdesignproblem. Gode ​​lag stiller styggere og derfor mer nyttige spørsmål. Hvor skjer kopien? Hvor er køhoppet? Hvilken side eier bufferen? Hvilken sti tildeler? Hva skjer under mottrykk? Hva er gjenspillbart? Hva kan benchmarkes isolert sett, og hva må benchmarkes ende-til-ende fordi lokale seire har lang tradisjon for å bli globale skuffelser?

Utbyttet av klarhet i grenser er ikke bare ytelse. Det er organisatorisk fornuft. Når sømmer er eksplisitte, kan team dele ansvar uten å miste ansvar. Ytelsesingeniører vet hva de skal måle. Plattformfolk vet hva de ikke skal berøre tilfeldig. Sikkerhets- og risikoteam kan resonnere om feilflater. Kjøpere og ledelse får en teknisk lesning som stopper rommet fra å krangle i sirkler. En god grense hjelper ikke bare kompilatoren. Det hjelper selskapet.

Det er en av grunnene til at HFT arkitektur drar nytte av en samarbeidende, økosystemorientert holdning i stedet for en helteholdning. De beste systemene bygges vanligvis ikke av én person som beviser renhet. De er bygget av en gruppe som er så grundig enige om grensesnitt, målinger og feileierskap at systemet fortsatt kan forklares selv når markedet slutter å være vennlig.

Praktiske saker verdt å løse først

Det smarteste første prosjektet er sjelden «rewrite the hot path». Det er den tekniske ekvivalenten med å gå inn i et hus og bestemme den første nyttige handlingen er å bytte ut hele skjelettet før du sjekker hvilket rør som allerede oversvømmer kjøkkenet.

Det bedre første prosjektet er ett av disse:

Fôrbehandler bevisarbeid

Hvis teamet krangler om hvorvidt parsing, normalisering, kø eller overlevering virkelig er latensproblemet, bygg bevisveien først. Fang representativ trafikk, spill den deterministisk på nytt, og tving systemet til å innrømme hvor tid og jitter faktisk kommer inn i kjeden. De fleste HFT systemer trenger ikke mer ideologi her. De trenger en bedre løgndetektor.

Denne bevisveien bør være god nok til at det samme sporet kan brukes av prestasjonsfolk, utviklere og ledere når en hard prioriteringssamtale er nødvendig. Når timinghistorien blir delt, forsvinner halve den politiske friksjonen fordi rommet ikke lenger forhandler med rykter.

Gateway og risikogrenseopprydding

Mange stabler blir ikke ødelagt av kjernestrategilogikken. De er ødelagt av grensesurvet mellom risiko, gateway-logikk og operasjonell koordinering. En forsiktig omskriving eller omstrukturering i disse sømmene kan forbedre påliteligheten og diagnostiseringen uten den kommersielle risikoen ved å berøre den absolutt hotteste sløyfen først.

Det er også her sterkere språkgarantier kan skape reell økonomisk verdi. Hvis ordrevalidering, struping og risikomeldinger blir lettere å resonnere rundt, blir hele systemet roligere. Rolige systemer er raskere å endre og billigere å styre.

Hybrid kontroll-plan opprydding

Hvis operatørverktøy, distribusjonshjelpere, gjenopprettingsverktøy eller replay-verktøy er skjøre, kan Rust være en sterk kandidat der. Disse komponentene former ofte helsen til hele organisasjonen selv når de ikke sitter i den raskeste mikrosekundbanen. Renere verktøy kan gjøre det varme systemet roligere uten å late som om hver binær i boet fortjener det samme språket.

Den skjulte gevinsten her er helse. Bedre verktøy reduserer mengden 02.00 arkeologi et team må utføre bare for å svare på grunnleggende operasjonelle spørsmål. Det betyr færre nødritualer, færre sprø enmannssystemer og bedre langsiktig teknisk samarbeid. I modne ingeniørorganisasjoner betyr det mer enn folk sier høyt.

Hands-On Lab: Bygg en liten sekvens-gap-detektor og gjør den ærlig

La oss holde laboratoriet lite og nyttig. HFT systemer lever og dør av sekvensdisiplin lenge før de når glamorøs strategilogikk. Dette leketøysprogrammet spiller av en strømlignende strøm og rapporterer hvor hull dukket opp.

Poenget med øvelsen er ikke at du skal distribuere denne eksakte koden. Poenget er å lære vanen med å bevare deterministisk tilstand under press. Sekvensdisiplin er et av de første stedene hvor et handelssystem enten beviser at det respekterer bevis eller beviser at det fortsatt bløffer.

main.cpp

#include <cstdint>
#include <iostream>
#include <string>
#include <vector>

struct Packet {
    std::uint64_t seq;
    std::string payload;
};

struct Gap {
    std::uint64_t expected;
    std::uint64_t received;
};

class GapDetector {
public:
    void on_packet(const Packet& packet) {
        if (!started_) {
            expected_ = packet.seq + 1;
            started_ = true;
            return;
        }

        if (packet.seq != expected_) {
            gaps_.push_back({expected_, packet.seq});
        }

        expected_ = packet.seq + 1;
    }

    const std::vector<Gap>& gaps() const {
        return gaps_;
    }

private:
    bool started_ = false;
    std::uint64_t expected_ = 0;
    std::vector<Gap> gaps_;
};

int main() {
    std::vector<Packet> replay{
        {1001, "AAPL bid"},
        {1002, "AAPL ask"},
        {1003, "MSFT bid"},
        {1007, "MSFT ask"},
        {1008, "NVDA bid"},
        {1011, "NVDA ask"}
    };

    GapDetector detector;
    for (const auto& packet : replay) {
        detector.on_packet(packet);
    }

    if (detector.gaps().empty()) {
        std::cout << "no gaps\n";
        return 0;
    }

    for (const auto& gap : detector.gaps()) {
        std::cout << "gap expected=" << gap.expected
                  << " received=" << gap.received << "\n";
    }
}

Bygge

På Linux eller macOS:

g++ -O2 -std=c++20 -o gap_detector main.cpp
./gap_detector

På Windows:

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

Forventet utgang:

gap expected=1004 received=1007
gap expected=1009 received=1011

Hvorfor denne lille øvelsen er viktig

Fordi det tvinger frem den riktige typen tenkning:

• deterministisk tilstandsoppdatering
• ærlig sekvensering
• replay før teori
• avgrenset, målbar atferd

Det er allerede mer HFT enn et overraskende antall konferanselysbilder.

Hvis du vil gjøre øvelsen mer realistisk, kan du legge til tidsstempler, pakker som ankommer sent og stedsspesifikke økter. Det som betyr noe er ikke å gjøre koden mer teatralsk. Det som betyr noe er å bygge refleksen om at enhver påstand om dataflyt skal være testbar, avspillbar og liten nok til å forklare.

Testoppgaver for entusiaster

1. Port den samme detektoren til Rust og sammenlign ikke benchmark-forfengelighet, men grenseklarhet, avhengighetsfriksjon og hvor enkelt hver versjon passer til ditt eksisterende verktøy.
2. Forleng avspillingen slik at manglende pakker senere kan komme ut av drift, og avgjør om detektoren skal bufre, avvise eller flagge dem.
3. Legg til timing og mål forskjellen mellom en vektor-støttet replay og en ring-buffer-støttet replay.
4. Introduser én unødvendig allokering på den varme banen og mål hvor raskt en "liten" beslutning begynner å forurense resultatet.
5. Legg til en logggren i on_packet og se hvor raskt observerbarhet blir sabotasje når den plasseres uforsiktig.

Sammendrag

Den virkelige C++ og Rust samtalen i HFT handler ikke om hvilket språk som fortjener den finere mytologien. Det handler om hvilke deler av systemet som trenger direkte kontroll, hvilke deler som drar nytte av sterkere standardinnstillinger, og hvilke grenser som kan gjøres ærlige nok til å støtte hybriddesign uten vrangforestillinger.

C++ dominerer fortsatt de hotteste HFT-banene fordi domenet belønner kontroll over minneoppsett, kødannelse, ledningsatferd, profilering, replay og integrasjon med et modent økosystem med lav latens. Rust er nyttig der korrekthet, eksplisitt og vedlikeholdsvennlighet skaper mer verdi enn ekstra økosystemfriksjonskostnader. Begge kan høre til i en seriøs stabel. Voksentrekket er å bestemme hvor, og å la bevis i stedet for språkfandom holde poeng.

Lag som får dette riktig gjør noe veldig uglamorøst og veldig effektivt. De slutter å spørre hvilket språk som vil redde dem og begynner å spørre hvilken grense som fortjener hva slags disiplin. Det skiftet høres beskjedent ut, men det er forskjellen mellom arkitektur som merkevarebygging og arkitektur som operasjonell sannhet. I HFT eldes sannheten vanligvis bedre.

Referanser

1. NASDAQ TotalView-ITCH spesifikasjon: ITCH
2. FIX Handelsfellesskapsstandarder: FIX
3. DPDK-dokumentasjon: https://doc.dpdk.org/guides/
4. Linux dokumentasjon for tidsstempling: Linux
5. Brendan Gregg på Flame Graphs: https://www.brendangregg.com/flamegraphs.html
6. Rust Performance Book: Rust