TL;DR: I’m a C++ trading systems programmer - but I recommend you use Python. Here’s why.
There is a great misconception with algotrading: that, at heart it’s a race - the first bid in the market will get the profit-making trade. Just as Michael Lewis explained in Flash Boys.
In fact algotrading is a race, just not that one.
It’s instructive to read the various discussion sites on the subject (HackerNews, Reddit, etc). You come away with the idea that algotrading is all about eking that last nanosecond out of your exchange connection. That, or using cunning techniques to optimise pricing calculations: get that order in first! Of course, it has to be in C++ (or Rust or other compiled languages) or you can’t keep up.
But that’s not what algotrading is about at all. (See below for what it is all about). Why does everyone get it so wrong? The reason is that those few top market-makers and prop firms who do agonise about nanoseconds get such a frenzy of attention as to drown out any other point of view. The fact that they pay breathtakingly well is much to do with this!
This blog is written to in some way remedy that.
Fundamentally, all algotraders play the same game. They search for signals that yield alpha and automate trading on them. Alpha is a systematic advantage over other market participants that should yield profit. The big players look everywhere for alpha. They have the resources, so they can use colocation¹, FPGAs² - and very skilled low-latency engineers - to examine market microstructure for tiny advantages.
But it’s not only at the micro level that alpha resides! Profit-yielding signals can - and are - discovered at many different levels. A great example can be found in another of Michael Lewis’ books The Big Short, who’s great trade unfolded over multiple years.
However, most opportunities are a combination of events and discovery. A simple example might be new law allowing pension funds to buy futures (the event). The “discovery” is their need to hedge. The opportunity is to trade the underlying. Normally it’s more subtle than that. Small mispricings may occur for technical reasons. So: determine the cause - and effect. Apply leverage. Deploy the code. Systematically scale-up across all effected securities. A fortune can be made - but you have to be quick! Once everyone knows - the opportunity is lost.
But the speed we’re talking about here is not measured in nanoseconds - it’s days or hours. It’s the time taken to write the algo. Ask anyone who’s written in both C++ and Python. They will attest that getting functioning code going is - at least - 10 times faster in Python. While your code may execute much faster in C++ - you’ll be a week late to the party.
In the crypto world in particular there is a wealth of alpha possibilities for algos. It’s such a new asset class. There is endless innovation leading to complex interactions that are difficult to unpack. The first to do so - and code it up - gets the prize of profit. Arbitrage between exchanges; between DeFi and centralised; new coins; smart contracts. But one thing is for sure: there’s no point wasting time fixing C++ bugs.
And anyway, if you really find a performance bottleneck you can implement that part using C++ and integrate it with relative ease into Python - e.g. with PyBind11³ - see my example of Parquet in our webinar from a few months ago. Better still this has already been done for almost all applications, e.g. Pandas⁴, SciPy⁵, NumPy⁶ and a huge host of others.
And it’s not just me who’s saying so. Most big firms have many desks who stategise independently. Newsflash: they don’t all use C++! Many use pure Python and make great profits. A number of top tier firms don’t use C++ at all. They use Java-based languages instead or even esoteric languages like Ocaml⁷ or Clojure⁸. They knowingly leave some latency on the table. Why? It’s not worth the effort.
If you are anything but a large firm who can pay for colocation and top C++ coders let me give you some advice: don’t waste your time with C++. That’s time your Python code could be making you money.