Source: 5+ years in HFT development
Edit: actually, see my response to the neighboring comment too.
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)
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
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.