C++, Rust, og højfrekvent handel: Hvor deterministisk latens bestemmer argumentet

Introduktion

Debatter på programmeringssprog tolereres normalt, fordi de fleste systemer har råd til lidt teater. En tjeneste er en smule ineffektiv, en kø bliver bredere, end den burde, en genforsøgspolitik gør noget moralsk tvivlsomt, og alle bliver ved med at bevæge sig, fordi produktet stadig virker, omsætningen lander stadig, og latensdiagrammet er grimt på en overlevelsesværdig måde. Hold kan bruge uger på at skændes om renhed, fordi systemet i sig selv er høfligt nok til ikke at smække dem med det samme.

Højfrekvent handel er mindre sentimental. Det er ligeglad med, hvilket sprog der vandt internettet i dette kvartal, hvilken konferencetale havde de reneste slides, eller hvilket omskrivningsinitiativ, der fik folk til at føle, at fremtiden endelig var ankommet. Det bekymrer sig om markedsdata bliver til stat, stat bliver en beslutning, og beslutningen bliver en ordre, før vinduet lukker. I den slags omgivelser bliver elegante meninger, der ikke kan overleve måling, røget hurtigt og normalt uden varsel.

Derfor er spørgsmålet om C++ og Rust i HFT interessant. HFT er et af de sjældne domæner, der tvinger hele argumentet til at udbetale i faktisk systemadfærd. Den varme sti holder enten sin form under pres, eller også gør den ikke. Halelatens forbliver enten disciplineret, eller også gør den det ikke. Replay fortæller enten sandheden, eller også gør den ikke. Arkitektur er ikke en personlighedstest der. Det er en faktura med et ur vedhæftet.

Og HFT er usædvanlig ærlig omkring, hvor regningen kommer fra. Omkostningerne starter før og efter matchnings- eller udførelsesvinduet. De akkumuleres i feed-parsing, bogvedligeholdelse, serialisering, kommunikation på tværs af kerner, jitter under belastning og alle de små "sandsynligvis fine" beslutninger, der bliver offentlig ydmygelse, når først systemet er udsat for ægte spillestedstrafik. Markedet har en grusom gave til at konvertere vagt ingeniørsprog til eksakte tab.

Det er også derfor, at svaret ikke er "C++ for evigt" eller "omskriv alt i Rust, fordi sikkerhed er godt, og frygt er en forretningsmodel." Det mere ærlige svar er smallere og derfor mere brugbart. C++ dominerer stadig de hotteste HFT-stier, fordi den omgivende verden af ​​værktøj, foderhåndtering, hukommelseskontrol, profilering og hardware-tilstødende praksis forbliver ekstremt C++ formet. Rust er virkelig nyttig omkring den kerne, og nogle gange inde i nøje udvalgte dele af den, men det sletter ikke det grundlæggende faktum, at handel med lav latency straffer abstraktionsfejl hurtigere, end de fleste hold kan omdøbe initiativet.

Så den rigtige samtale handler ikke om identitet. Det handler om systemgrænser. Hvilke dele af stakken har brug for brutal kontrol over hukommelse, layout, køer, affinitet og trådadfærd? Hvilke dele har størst gavn af stærkere korrekthedsbegrænsninger og sikrere standardindstillinger? Hvilke dele fortjener hybridbehandling i stedet for stammerenhed? De spørgsmål er langt mindre glamourøse end sprogprædikener, men det er også de spørgsmål, der overlever kontakten med produktionen, og de spørgsmål, der lader teams samarbejde omkring beviser i stedet for slogans.

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

HFT er usædvanligt god til at afsløre en velkendt ingeniørløgn: løgnen om, at gennemsnitlig adfærd er nok. I mange almindelige produkter kan et system forblive respektabelt, mens det skjuler lejlighedsvis kaos bag gennemløb, genforsøg eller brugerens tålmodighed. I HFT er gennemsnitlig latenstid interessant, men haleadfærd er ofte den del, der faktisk ydmyger dig. Et system, der ser hurtigt ud, indtil det rykker på det forkerte tidspunkt, er ikke et hurtigt system i nogen kommercielt meningsfuld forstand. Det er et selvtillidstrick med et benchmark tilknyttet.

Det er derfor, HFT ingeniører bliver allergiske over for upræcise abstraktioner. De lærer, at en ekstra tildeling på den varme vej ikke er "bare en tildeling." Det er en mulig kilde til jitter. Et køhop er ikke "bare et køhop." Det er et andet sted, hvor tiden bliver gemt, koordinationen udvides, og synligheden bliver dårligere. Én cache-fjendtlig struktur bliver en løbende skat på enhver markedsbegivenhed, der passerer gennem systemet. Gang det med reelt fodervolumen, og pludselig bliver et designvalg fra et slide deck en tilbagevendende linjepost i budgettet til skuffelse.

Det grusomme ved domænet er, at det også straffer delvise forklaringer. Et hold kan identificere en åbenlys latenskilde og stadig gå glip af den rigtige lovovertræder, fordi kæden er kumulativ. En beslutning om hukommelseslayout udvider cache-miss-profilen. Det udvider køvinduet. Det ændrer, hvordan systemet opfører sig under sprængtrafik. Det ændrer rækkefølgen, som "sjælden" grenadfærd viser sig. Så går nogen ind i obduktionen og siger, at problemet var "netværksstøj", som er ingeniørkode for "vi er ikke færdige med at fortælle sandheden endnu."

Rust går ind i denne samtale med legitim kraft, fordi hukommelsessikkerhed betyder noget, samtidighed er korrekt, og systemkode fortjener bedre standardindstillinger end "vær forsigtig, mens du jonglerer med knive over en pit." Den del er sand. Men HFT belønner ikke sandheden isoleret. Det belønner kombineret sandhed. Sikkerhed betyder noget, ja. Det samme gør modne foderbehandlere, stabile ABI grænser, replay-værktøjer, profildrevet iteration, moden udvekslingsintegrationskultur og evnen til at inspicere præcis, hvad maskinen gør, når markedet er uvenligt. C++ kommer stadig med mere af den omkringliggende infrastruktur i de fleste HFT miljøer.

Dette er en af ​​grundene til, at teams og ingeniørledere bør modstå renhedsfortællinger. Et sprog kan være fremragende i en snæver dimension og stadig være den forkerte standard for den mest timingfølsomme del af en stak, hvis det omgivende økosystem, værktøj og teamoplevelse ikke understøtter den faktiske leveringssti. HFT er hvor dejlige lokale sandheder går for at lære, at hele vejen stadig betyder mere. Stakken er ligeglad med, at en påstand var moralsk elegant, hvis det resulterende system er operationelt usammenhængende.Det er også her holdøkologi betyder mere, end folk indrømmer. Et samarbejdende hold med en disciplineret replay-sele, et fælles latensordforråd og kedeligt gode profileringsvaner vil normalt udkonkurrere et mere moderigtigt hold, der bliver ved med at forvirre smag for beviser. HFT belønner stærk teknisk kultur mere pålideligt end den belønner moderigtig migrationsenergi.

Stakken er ikke én ting, så sprogvalget bør ikke foregive andet

En af de dummeste fejl i seriøst systemarbejde er at tale om "HFT-stakken", som om det var en enkelt teknisk organisme med ét foretrukket sprog. Den fejler den test. Det er en samling af stier med meget forskellige pres og fejlomkostninger.

Stien til indtagelse af markedsdata har ét temperament. Stien til opdatering af ordrebog har en anden. Strategilogik kan være numerisk tæt, men strukturelt snæver. Risikotjek er ofte latenstidsfølsomme, men også korrekthedsfølsomme på en kedelig, voksen, juridisk konsekvensmæssig måde. Simulerings- og afspilningsinfrastruktur kan sætte pris på determinisme og introspektion frem for rå nanosekunds forfængelighed. Kontrolplanværktøjer, implementeringshjælpere og operatøroverflader bekymrer sig langt mere om pålidelighed, vedligeholdelse og integrationshygiejne, end de bekymrer sig om at barbere fem mikrosekunder fra en sti, som ingen kunde nogensinde vil se.

Der er også menneskelige operationelle forskelle mellem disse lag. Nogle stier ændres dagligt af et bredere team. Nogle røres sjældent og kun under opsyn. Nogle komponenter har brug for aggressiv sporbarhed, fordi overholdelse eller revision i sidste ende vil stille svære spørgsmål. Nogle har kun brug for stram præstation og fremragende genspil. At behandle dem som én beslutning er, hvordan organisationer ender med enten at overmodernisere rolige komponenter eller understyre farlige.

Dette betyder noget, fordi det ofte er her, en fornuftig C++ og Rust samtale begynder. C++ forbliver stærkest, når stien er brutalt varm, hardwarebevidst, integrationstung og allerede omgivet af mange års indfødt operationel praksis. Rust bliver mere attraktiv, når stien stadig er vigtig, men den økonomiske værdi af stærkere standarder, klarere ejerskab og snævrere eksponering for hukommelsesrisiko opvejer omkostningerne ved økosystemfriktion.

I praksis fører det ofte til hybride resultater. De hotteste foderhåndterings- og gateway-stier forbliver i C++. Replay-værktøjer, konfigurationsvalidering, visse hjælpere på risikosiden, meddelelsesnormaliseringsværktøjer, revisionsværktøjer eller interne operatør-vendte komponenter kan være fremragende Rust-kandidater. Dette er arkitektonisk voksenliv. Systemet bliver behandlet som et sæt reelle grænser snarere end som et sprogfandom med et datacenter.

Og det er her, mange omskrivningsforslag endelig bliver ærlige. Når et hold kortlægger stakkens sti for sti, har fantasien om et enkelt universelt svar en tendens til at kollapse. Det sammenbrud er sundt. Det giver organisationen tilladelse til at optimere for evidens, vedligeholdelse, operationel tillid og leveringsrytme i stedet for den følelsesmæssige komfort ved at have et simpelt slogan.

Hvor C++ stadig ejer de hotteste stier

C++ beholder sin plads i HFT af årsager, der er mindre mystiske, end udenforstående nogle gange forestiller sig. Den første grund er hukommelse og layout kontrol. HFT hot paths bekymrer sig om, hvilke data der lever sammen, hvordan strukturer opfører sig i cache, hvordan ejerskab dukker op under belastning, og om systemet kan forblive allokeringsdisciplineret, når markedet holder op med at være høfligt. C++ giver stadig ingeniører usædvanlig direkte brug over disse valg, og det gør det i et økosystem, der allerede har brugt årtier på at lære, hvilke "små" omkostninger der er hemmeligt store.

Den anden grund er værktøjstæthed. C++ i HFT betyder ikke kun et sprog. Det betyder kompilatorer, desinfektionsmidler, flammegrafer, HFT, VTune, replay-seler, udvekslingsadaptere, folklore i kø, allokatorekspertise og en lang række præstationskrigshistorier samlet under økonomisk pres. Hold starter ikke fra nul der. De arver en dyb operationel kultur, og den kultur betyder noget, fordi HFT belønner målt iteration langt mere end retorisk renlighed.

Den tredje grund er integrationens tyngdekraft. Udvekslinger, native netværksstier, pakkeopsamlingsværktøjer, kerne-tilstødende optimering, FPGA-tilstødende infrastruktur og hele økosystemet med lav latens er stadig meget komfortable i en C- og C++-verden. Rust kan interagere med den verden, og nogle gange meget effektivt, men "kan interagere med" er ikke det samme som "er den mindste friktions vej gennem hele systemet." I seriøse HFT er friktion ikke en følelsesmæssig besvær. Det er en mulig latensskat, en debuggingskat og en leveringsafgift på samme tid.

Der er også en mere subtil grund, der betyder mere i AI-æraen: C++ har simpelthen mere operationel hukommelse til rådighed omkring dette arbejde. AI-kodningssystemer, kodesøgning, offentlige eksempler, leverandøruddrag, optimizer-folklore og debugging-spor er tættere omkring C++ i systemer med lav latens end omkring Rust. Det gør ikke C++ ædlere. Det gør det lettere for mennesker og AI-værktøjer at samarbejde inde i grimme rigtige kodebaser, hvis charme udløb for år siden.

En anden fordel er, at mange HFT hold allerede har forvandlet C++ til institutionel muskelhukommelse. De ved, hvordan man profilerer det under pres på spillestederne. De ved, hvordan man fjerner tildelinger fra mistænkelige stier. De ved, hvordan "hurtigt nok i mikrobenchmark" lyder, når det er ved at blive falsk i produktionen. Den levede viden er driftsmæssigt værdifuld. Et team, der allerede ved, hvordan man holder C++ ærligt, bør ikke smide det let væk, bare fordi et nyere sprog føles renere isoleret.

Det er derfor C++ forbliver stærkest som et omgivende håndværkssystem, ikke som syntaks alene. Når først du tilføjer interne biblioteker, testseler, optagelsesværktøjer, trådaffinitetsvaner, frigør muskler og diagnosticeringsarbejdsgange, sammenligner du ikke længere et sprog med et andet i et vakuum. Du sammenligner et helt leveringsøkosystem med et andet. I HFT slår økosystemer ofte idealer.## Hvor Rust faktisk hjælper i stedet for at udføre moral

Rust hjælper de fleste, når det løser et reelt problem i stedet for at fungere som personlighedstilbehør til arkitekturdiagrammer. I HFT optræder de stærkeste Rust use cases ofte omkring den varme kerne i stedet for i det absolutte centrum af den.

Rust er nyttig til komponenter, hvor korrekthedsfejl er dyre, men latensbudgettet ikke måles med et mikroskop. Beskedvalideringslag, konfigurations- og implementeringsværktøjer, visse protokolnormaliseringsstier, kontroltjenester, administrative hjælpeprogrammer, offlineanalysatorer og interne operatørers værktøjer kan drage fordel af sprogets skævhed mod eksplicititet. Pointen der er ikke at se moderne ud. Pointen er at reducere klassen af ​​dumme, gentagne, strukturelt undgåelige fejl, der dræner opmærksomheden fra vigtigere arbejde.

Rust kan også hjælpe med omhyggeligt udvalgte næsten varme komponenter, når teamet har den rette ekspertise, og grænsen er ærlig. En parser med lav latens, en afgrænset tilstandsmaskine eller et stykke deterministisk infrastruktur kan være en solid Rust-kandidat, hvis holdet kan holde FFI og allokeringshistorien under kontrol, og hvis den omgivende økosystembyrde er forstået på forhånd i stedet for at blive opdaget kl. 2:40 om morgenen, ingen ønskede under en udrulning.

Det er også ofte hjælpsomt i arbejdet omkring arbejdet. Capture-processorer, offline bogafspillere, revisionshjælpere, implementeringsvalidering eller strategitilstødende infrastruktur nyder godt af strengere ejerskab og klarere grænseflader, selv når de ikke er den absolutte nanosekunds kampplads. Disse stykker betyder noget, fordi de bestemmer, hvor hurtigt holdet kan diagnosticere hændelser, reproducere anomalier og bevæge sig sikkert fra mistanke til bekræftet forståelse.

Men det er præcis her, hold har brug for disciplin. Rust er ikke værdifuldt, når det falder ind i midten af ​​en indfødt handelsstak som en trosbaseret renovering. Det er værdifuldt, når grænsen er ren, målestien er indlysende, og driftsomkostningerne ved integrationen er lavere end den sikkerheds- eller vedligeholdelsesgevinst, den skaber. Ellers bliver projektet et smukt casestudie i, hvordan man bruger seriøs ingeniørtid på at flytte usikkerhed sidelæns.

Det rigtige anti-mønster bruger Rust til at skjule fraværet af arkitektonisk klarhed. Hvis teamet ikke kan forklare, hvor ejerskab begynder, hvor latens måles, hvor buffere krydser, og hvor restitution sker under stress, vil ændring af sproget ikke redde designet. Det vil bare gøre fiaskoen mere tosproget.

Grænsen betyder mere end prædikenen

En almindelig fejl i C++ versus Rust diskussioner er at antage, at brug af Rust automatisk fjerner fare. Det gør den ikke. Det ændrer, hvor faren sidder. I HFT er det grænsespørgsmål særligt vigtigt, fordi varme stier sjældent ender ved sproglinjen. De ender ved netværksgrænser, køgrænser, planlægningsgrænser, FFI grænser og grænser for datalayout.

Hvis en Rust-komponent skal krydse ind i en C++-udvekslingsadapter, tale med en indbygget kø, sende data til en strategimotor med stramme layoutantagelser eller opretholde deterministisk adfærd på tværs af grænseovergange, så er det egentlige ingeniørarbejde ikke "vi brugte Rust." Det virkelige arbejde er, hvor omhyggeligt sømmen blev defineret og verificeret. Usikker adfærd kan stadig komme gennem ABI mismatch, ejerskabsforvirring, skjulte kopier, køfejl eller tidsoverraskelser. Sproget alene er ikke din styringsmodel. Grænsen er.

Det er derfor, modne hold taler om en smal varm sti og en smal usikker overflade. De er ikke afhængige af slogans som "hukommelsessikkerhed som standard" for at løse, hvad der grundlæggende er et systemdesignproblem. Gode ​​teams stiller grimme og derfor mere brugbare spørgsmål. Hvor sker kopien? Hvor er køhop? Hvilken side ejer bufferen? Hvilken sti tildeler? Hvad sker der under modtryk? Hvad kan genspilles? Hvad kan benchmarkes isoleret, og hvad skal benchmarkes ende-til-ende, fordi lokale gevinster har en lang tradition for at blive globale skuffelser?

Grænseklarhed skaber også organisatorisk fornuft. Når sømmene er tydelige, kan teams dele ansvaret uden at miste ansvarlighed. Ydelsesingeniører ved, hvad de skal måle. Platformsfolk ved, hvad de ikke skal røre ved afslappet. Sikkerheds- og risikohold kan ræsonnere om fejloverflader. Hold og ledelse får en teknisk læsning, der forhindrer rummet i at skændes i cirkler. En god grænse hjælper compileren og virksomheden.

Det er en af ​​grundene til, at HFT arkitektur drager fordel af en samarbejdsorienteret, økosystemorienteret holdning frem for en heltestilling. De bedste systemer er normalt ikke bygget af én person, der beviser renhed. De er bygget af en gruppe, der er så grundigt enige om grænseflader, målinger og fejlejerskab, at systemet forbliver forklareligt, selv når markedet holder op med at være venligt.

Praktiske sager, der er værd at løse først

Det smarteste første projekt er sjældent "omskriv den varme vej." Det er den tekniske ækvivalent med at gå ind i et hus og beslutte, at den første nyttige handling er at udskifte hele skelettet, før man tjekker, hvilket rør der allerede oversvømmer køkkenet.

Det bedre første projekt er et af disse:

Feed-handler bevisarbejde

Hvis teamet skændes om, hvorvidt parsing, normalisering, kødannelse eller overdragelse virkelig er latensproblemet, skal du først bygge bevisstien. Fang repræsentativ trafik, gentag den deterministisk, og tving systemet til at indrømme, hvor tid og jitter faktisk kommer ind i kæden. De fleste HFT systemer har ikke brug for mere ideologi her. De har brug for en bedre løgnedetektor.

Den evidenssti burde være god nok til, at det samme spor kan bruges af præstationsfolk, udviklere og ledere, når der er behov for et hårdt prioriteringsopkald. Når først timinghistorien bliver delt, forsvinder halvdelen af ​​den politiske gnidning, fordi rummet ikke længere forhandler med rygter.

Oprydning af gateway og risikogrænseMange stakke er ikke ødelagt af kernestrategilogikken. De er ødelagt af grænseslethed mellem risiko, gateway-logik og operationel koordinering. En omhyggelig omskrivning eller omstrukturering i disse sømme kan forbedre pålideligheden og diagnosticeringen uden den kommercielle risiko ved først at berøre den absolut hotteste løkke.

Det er også her, stærkere sproggarantier kan skabe reel økonomisk værdi. Hvis ordrevalidering, drosling og risikobeskeder bliver nemmere at ræsonnere om, bliver hele systemet mere roligt. Rolige systemer er hurtigere at ændre og billigere at styre.

Hybrid kontrolplan oprydning

Hvis operatørværktøjer, implementeringshjælpere, gendannelsesværktøjer eller genafspilningsværktøjer er skrøbelige, kan Rust være en stærk kandidat der. Disse komponenter former ofte sundheden for hele organisationen, selv når de ikke sidder i den hurtigste mikrosekundvej. Renere værktøjer kan gøre det varme system roligere uden at lade som om, at hver binær i boet fortjener det samme sprog.

Den skjulte gevinst her er sundhed. Bedre værktøj reducerer mængden af ​​arkæologi kl. 02.00, som et team skal udføre bare for at besvare grundlæggende operationelle spørgsmål. Det betyder færre nødritualer, færre skrøbelige enmandssystemer og bedre langsigtet teknisk samarbejde. I modne ingeniørorganisationer betyder det mere, end folk siger højt.

Hands-On Lab: Byg en lille sekvens-gab-detektor og gør den ærlig

Lad os holde laboratoriet lille og nyttigt. HFT systemer lever og dør af sekvensdisciplin længe før de når glamourøs strategilogik. Dette legetøjsprogram afspiller en feed-lignende strøm og rapporterer, hvor der opstod huller.

Pointen med øvelsen er ikke, at du vil implementere denne nøjagtige kode. Pointen er at lære vanen med at bevare deterministisk tilstand under pres. Sekvensdisciplin er et af de første steder, hvor et handelssystem enten beviser, at det respekterer beviser eller beviser, at det stadig bluffer.

Rust```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 onpacket(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::uint64t 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";
}

}

På Linux eller macOS:```bash
g++ -O2 -std=c++20 -o gap_detector main.cpp
./gap_detector
```På Windows:```powershell
cl /O2 /std:c++20 main.cpp
.\main.exe
```Forventet output:```text
gap expected=1004 received=1007
gap expected=1009 received=1011
```### Hvorfor denne lille øvelse betyder noget

Fordi det tvinger den rigtige form for tænkning:

* deterministisk tilstandsopdatering
* ærlig sekventering
* Genspil før teori
* afgrænset, målbar adfærd

Det er allerede mere HFT end et overraskende antal konference-dias.

Hvis du vil gøre øvelsen mere realistisk, skal du tilføje tidsstempler, pakker, der ankommer sent, og stedspecifikke sessionsnulstillinger. Det, der betyder noget, er ikke at gøre koden mere teatralsk. Det, der betyder noget, er at opbygge den refleks, at enhver påstand om dataflow skal være testbar, genafspillelig og lille nok til at forklare.

## Testopgaver for entusiaster

1. Port den samme detektor til Rust og sammenlign grænseklarhed, afhængighedsfriktion og pasform med dit eksisterende værktøj.
2. Forlæng afspilningen, så manglende pakker senere kan komme ud af drift, og beslut derefter om detektoren skal buffere, afvise eller markere dem.
3. Tilføj timing og mål forskellen mellem en vektor-understøttet replay og en ring-buffer-backed replay.
4. Indfør én unødvendig allokering på den varme vej og mål, hvor hurtigt en "lille" beslutning begynder at forurene resultatet.
5. Tilføj en logningsgren inde i HFT og se, hvor hurtigt observerbarhed bliver til sabotage, når den placeres skødesløst.

## Resumé

Den rigtige C++ og Rust samtale i HFT handler ikke om, hvilket sprog der fortjener den pænere mytologi. Det handler om, hvilke dele af systemet, der har brug for direkte kontrol, hvilke dele, der nyder godt af stærkere standardindstillinger, og hvilke grænser der kan gøres ærlige nok til at understøtte hybriddesign uden illusion.

C++ dominerer stadig de hotteste HFT-stier, fordi domænet belønner kontrol over hukommelseslayout, kødannelse, ledningsadfærd, profilering, genafspilning og integration med et modent økosystem med lav latency. Rust er nyttigt, hvor korrekthed, eksplicithed og vedligeholdelse skaber mere værdi end yderligere økosystemfriktionsomkostninger. Begge kan høre til i en seriøs stak. Det voksne træk er at bestemme hvor, og at lade beviser frem for sprogfandom holde score.

Hold, der får dette rigtigt, gør noget meget uglamorøst og meget effektivt. De holder op med at spørge, hvilket sprog der vil redde dem og begynder at spørge, hvilken grænse der fortjener hvilken slags disciplin. Det skift lyder beskedent, men det er forskellen mellem arkitektur som branding og arkitektur som operationel sandhed. I HFT ældes sandheden normalt bedre.

## Referencer

1. NASDAQ TotalView-ITCH specifikation: Rust
2. FIX Handelsfællesskabsstandarder: C++
3. DPDK-dokumentation: ITCH
4. Dokumentation til Linux tidsstempling: FIX
5. Brendan Gregg om Flame Graphs: Linux
6. Rust Performance Book: [https://nnethercote.github.io/perf-book/](https://nnethercote.github.io/perf-book/)