Because big money will trade enough dollar value as to change the price by their action so whoever is second missed the opportunity.

Languages like python are immediately out, they make no attempt to be fast (which is fine for their niche). Even languages like Java are out, the JVM is too smart: it turns out that the algorithm needs to analyse a few thousand possible trades where the answer no trade before it gets one where the answer is yes, as a result Java will optimize for the common no path. In C++ the programmer will lie to the optimizer claiming that the yes path is the most likely even though it isn't! As a result code written in C++ will always have the yes path as most optimal: when a trade should be made the java program pays a CPU branch misprediction penalty and the C++ program will not thus C++ wins the trade. Of course for the above to work you need cleaver programmers who spend time at the profiler and know how to make the CPU work for them.

C++ has one other useful advantages over some of the competition: it won't waste CPU checking for things like dereferencing a null pointer. Speed is important, you should verify via other means (unit tests, formal methods static analysis, or have the checks that you run on dummy data and compile without them for production)

Thus C and C++ are the only useful choices: the compilers have good optimizers (this rules out a lot of other compiled languages), they don't use CPU to check for "can't happen" errors, and you can lie to the optimizer in useful ways. There are other advantages, but the rest are things that a good programmer could easily work around (ie write a new stat structure from your CS textbook)

this blew my mind :)

Every microsecond counts. We've done some pretty crazy sounding things to get the last bit of juice out of the system:

1. Write a converter to convert a proprietary interpreted business rule language to C++

2. Make all messages fit the maximum ethernet frame size to avoid fragmentation overhead

3. Make the transported message format the same as the memory object format to avoid the packing/unpacking overhead

4. Predict and pre-allocate object pools in heap memory to avoid heap lock overhead

5. Statically link all libraries

6. Optimize key functions at assembly level

7. Turn all record ID's into zero based indexes and covert most lists and maps into arrays for rapid lookup

8. No indexes or foreign constraints in the rapid-write areas of DB

9. Hand rolled on-disk cache file formats that only operate in append mode to prevent seek overhead

10. And finally (this was after my time) trying to implement the TCP stack in FPGA

For HFT, it's not that every second counts, is that every millisecond (or even lower) counts. You're competing with other, similar algorithms for picking up opportunities. The assumption is that you're not capital constrained, you (or the competitors) can immediately exploit all the volume of such an opportunity, the deals you submit shift the prices so that it disappears.

This means that whoever is not the first to take that opportunity doesn't get it, and if you're reliably a millisecond slower than a competitor then you might as well not even try.

A lot of algorithms are dependent on the ability to execute quickly. If yours is not, then PL doesn't matter (at least, in the respect the parent was discussing).