C++ and Python in HFT: which language is used where, and why

Where the boundary falls

A simplified map of a high-frequency stack, and the language that normally owns each layer:

Two observations follow. First, the hot path is a small fraction of the codebase and a large fraction of the difficulty. Second, everything above the millisecond line is where most of the firm's code lives and where most of its people work.

Why C++ wins the hot path

The reason is not raw instruction speed. It is control and predictability.

Deterministic memory. A garbage-collected runtime can pause at an arbitrary moment. In a system where a microsecond of jitter loses a queue position, a pause of even a few hundred microseconds is a loss event. C++ lets the engineer decide exactly when memory is acquired and released, which in practice means acquiring it all at startup.

Cache control. At these latencies, the dominant cost is memory access, not computation. C++ gives direct control over data layout, so hot structures can be packed to fit cache lines and laid out contiguously. A structure-of-arrays rewrite routinely beats an algorithmic improvement.

Zero-cost abstraction. Templates allow abstraction that compiles away entirely, so code can be readable without paying for it at runtime.

Direct hardware access. Kernel bypass libraries, custom NIC drivers, CPU pinning, huge pages and explicit prefetching are all reachable from C++ with no intermediary.

The dialect actually used

Production HFT C++ looks different from general application C++, and this surprises candidates arriving from other domains. On the hot path, typical constraints include:

• No dynamic allocation after startup. Memory is pre-allocated into pools and arenas.
• No exceptions, and often no RTTI. Error handling is by return value or status code.
• No virtual dispatch on the hot path. Polymorphism is resolved at compile time with templates or CRTP.
• Limited standard library use. Containers that allocate or that have unpredictable layout are replaced with in-house equivalents.
• Branch-free or branch-predictable logic where possible, with explicit hot and cold path annotation.
• Extensive compile-time computation, so that work happens once rather than per message.

Interviewers test for exactly this. A candidate who writes correct, idiomatic modern C++ but reaches for std::map, shared_ptr and exceptions in a message-handling loop signals that they have not worked in this environment.

Why Python owns research

It would be a mistake to read the latency table as a hierarchy of importance. A firm's durable edge is the rate at which it tests and retires hypotheses, and that rate is set by the research platform.

Python wins there because the cost that matters is a researcher's time. The numerical and data ecosystem of array libraries, dataframes, statistical and machine learning toolkits and notebooks means a hypothesis can go from idea to tested result in an afternoon. The performance problem is largely solved by delegation: the heavy numerical work runs in compiled libraries, and firm-specific cores are written in C++ and exposed to Python through bindings. The researcher writes Python; the computation happens in C++.

This hybrid pattern is now the industry standard. A well-built research platform gives researchers a Python interface over a C++ simulation engine that shares code with production, so that a strategy tested in research is executed by the same logic in the live system. Building and maintaining that boundary is one of the most valuable quantitative developer specialisms in the market.

Where Rust fits

Rust has real adoption in trading firms, concentrated in new services rather than in rewrites of the hot path: order management, risk services, data infrastructure, exchange connectivity for newer venues, and crypto trading systems built from scratch in the last few years.

The argument for it is memory safety without a garbage collector, a strong type system and modern tooling. The arguments against displacing C++ in established hot paths are practical: decades of existing C++, deep in-house libraries, a far larger hiring pool, mature profiling and debugging tooling at the nanosecond scale, and the fact that the hot path is written in a restricted dialect where C++'s historical safety problems are substantially mitigated by convention and review.

The reasonable expectation is continued growth in adjacent systems and in newer firms, with C++ remaining dominant in the latency-critical path at established ones for the foreseeable future.

Talent implications

For hiring managers. The language in a job specification is a proxy for a layer of the stack, and stating the layer produces better candidates than stating the language. "Senior C++ engineer" attracts a very wide field; "feed handler and book-building engineer, sub-microsecond, kernel bypass, Indian equity derivatives" attracts a narrow and relevant one.

Three specific points worth building into a brief:

• A candidate's C++ seniority elsewhere does not transfer automatically. Game engine, embedded and systems backgrounds transfer well because the constraints are similar. Enterprise and application C++ transfers less well.
• Python-only candidates are the right hire for research tooling and data platform roles, and this is a large and genuinely senior market. Treating these as junior roles is a common and costly mistake.
• The scarcest profile is the engineer who can hold both: production C++ depth plus enough statistical literacy to build and defend a research platform. Expect to pay for it and expect a long search.

For candidates deciding what to learn. Work backwards from the role.

The common error among candidates is breadth without depth: a CV listing six languages reads worse than one demonstrating that the candidate has made something measurably fast and can explain exactly why it is fast.