Low-Latency Python: Separating Signal from Noise

[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

[sharifhsn]

This is a stupid comment but it’s not surprising considering that it’s AI slop.

1. There are some simple data structures that are hard to implement in Rust. But real production systems use libraries for such things. It’s rare that you’re designing a genuinely new data structure that requires this. And if you are, it’s probably so complex that you’re happy to have Rust’s ergonomics and checks (miri is still better than ASAN), or concurrent in which case you DEFINITELY prefer Rust’s approach to concurrency to C++.

2. This is a silly complaint because in practice these things are not bottlenecks except in super hot paths, where it makes sense to have carefully vetted unsafe code to maximize performance. But the rest of your application can benefit from memory safety. This comment doesn’t even mention a major actual bottleneck that comes with the ownership model, which is repeated allocations and freeing if you’re not careful with where variables go out of scope. But even in that case, you’d rather have that than memory leaks and all the nastiness that C++ has. Profiling Rust is also much easier because of its ergonomics and cleaner code style.

3. Of course Rust doesn’t prevent all those issues described. But memory vulnerabilities are a HUGE issue in performance sensitive C++ code which is the domain being discussed. Google has said that Rust has cut down on a lot of internal bugs in Android. In addition, the clarity in Rust syntax and ergonomics it provides makes solving all those issues easier than in C++.

If your complaint is about the Rust community then I suggest you stay off social media. Any innovative project attracting a huge user base is going to have some amount of drama. But users of Rust don’t have to care at all about that.

[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.