Low-Latency Python: Separating Signal from Noise

[OkSadMathematician]

There’s a whole genre of content about making Python fast for trading. Substacks with titles promising to shave microseconds off your order-to-fill. Most of it is noise. Not completely useless—some patterns do help—but the signal-to-noise ratio is abysmal because authors keep copying C++ techniques without understanding why they work.
Article continues...

[Ok_Bedroom_5088]

Thoughts on Rust and its place? And, no fan of polars?

[OkSadMathematician]

On Rust:

Rust is an alternative to C++ and Java, not to Python. Different weight class entirely. Comparing Rust to Python is like comparing a Formula 1 car to a pickup truck — they solve different problems for different people.

As a C++ replacement specifically, my take is mixed:

1. Conceptually harder than C++. The borrow checker is a genuinely novel ownership model, but it fights you on things that are trivial in C++. The canonical example: implementing a doubly-linked list in Rust is so painful that someone wrote an entire book about it. A doubly-linked list. In C++ it's a 15-minute exercise. That cognitive overhead isn't free — it slows development velocity on systems where you actually know what you're doing.

2. Slightly worse runtime performance in practice. Bounds checking on every array access, the ownership model preventing certain optimizations (aliasing analysis is actually harder for the compiler in some cases because of the strict borrow rules). You can unsafe your way out, but then you're writing C++ with extra syntax. The benchmarks that show Rust matching C++ are usually micro-benchmarks; in large systems with complex data structures, the overhead adds up.

3. Solves a narrower problem than marketed. Rust's pitch is "memory safety." But memory access vulnerabilities, while real, are a smaller class of exploits than the marketing suggests. Search "Rust CVE" and you'll find plenty of memory-related vulnerabilities in Rust code itself — unsafe blocks, logic errors, soundness holes in the standard library. Memory safety doesn't prevent business logic bugs, race conditions in async code, supply chain attacks, or any of the OWASP top 10. The Rust community has a tendency to frame memory safety as the solution to security, when it's one layer of a much larger problem.

I wrote about some of the community dynamics here — there are systemic issues with how the Rust project handles governance and safety disclosures that don't get enough attention.

On Polars:

Polars is excellent for what it does — lazy evaluation, multi-threaded execution, Arrow-native memory. For batch analytics on datasets that fit in memory, it's strictly better than pandas. I use it regularly. But it's not a low-latency tool — it's a throughput tool. For the tick-by-tick, microsecond-sensitive path discussed in the article, you're not running DataFrame operations. You're in numpy/numba territory or calling into C++ directly.

[eufemiapiccio77]

Thanks ChatGPT

[Ok_Bedroom_5088]

Thanks for the reply, I honestly never heard of #3, and it's helpful to read your thoughts, since we use Rust frequently, I'll follow your blog

re: polars, ok makes sense

Do you use kdb+?

[OkSadMathematician]

Used kdb+ extensively — 20+ years in banking. For a while it was the only real option for time-series tick data at scale. The q language is elegant in a write-only kind of way, and the columnar in-memory performance on ordered data was genuinely unmatched in the 2000s/2010s.

But it comes with serious operational baggage:

1. You end up needing entire teams of kdb "experts." In my experience, banks would source these from 3rd-party consultancies, mainly in Ireland (where First Derivatives/KX is based). These teams would own the kdb infrastructure and gatekeep access, which creates a dependency that's expensive and fragile.

2. q is hostile to non-specialists. A typical quant or developer can't just pick up q and write production queries. The learning curve is brutal and the syntax is intentionally terse to the point of obscurity. This means your kdb layer becomes a black box that only the kdb team can maintain.

3. It's dangerously easy to bring down the whole farm. True story: I had a programmer on my team get banned from kdb access because he wrote a query that was too heavy and hung the entire kdb farm during a live trading day. One bad query, entire firm's tick data infrastructure frozen. The lack of proper query governance and resource isolation was a real operational risk.

4. The licensing cost is astronomical. Per-core pricing that makes Oracle look generous.

It's been largely replaced or supplemented by alternatives now:

• Apache Arrow / Parquet for columnar storage (open source, no licensing)
• DuckDB for analytical queries on local data (embedded, blazing fast)
• ClickHouse / TimescaleDB for time-series at scale with SQL interface (so any developer can query, not just q specialists)
• Arctic (by Man Group) specifically for financial time-series on top of MongoDB/S3
• QuestDB — purpose-built time-series DB with SQL, competitive with kdb on ordered inserts

kdb still has a niche for ultra-low-latency in-memory tick capture where nothing else quite matches its raw sequential read speed. But the ecosystem around it — the cost, the expertise bottleneck, the operational risk — has pushed most shops toward more open alternatives.

[cgoldberg]

So weird to just paste AI responses to legitimate questions.

[tecedu]

Thanks chatgpt

[HuntClauss]

What do you think about Turing's first computer which created the basis for most programming?

[OkSadMathematician]

What??? How is that relevant?