12 ms·
HFT gigs I’ve looked at were all C++, some even Rust now - because they don’t want the risk of a long GC pause messing up a trade (which means Java, .NET, and G
by DaiPlusPlus 8y ago
HFT gigs I’ve looked at were all C++, some even Rust now - because they don’t want the risk of a long GC pause messing up a trade (which means Java, .NET, and Go are right-out).
- dilyevsky 8y agoGo uses tri-color mark-and-sweep gc that runs concurrently and its latency is extremely short compared to .net and java (probably still not short enough to be put in the critical path of hft order processor tho). Edit: I'm also confident you can ensure Go’s gc doesn’t run when you don’t want it to so there’s that.
- dgoldstein0 8y agoThis may be true but conventional wisdom against using anything GC'ed for real-time applications (like HFT or aerospace stuff) is going to mean even if go's gc is good enough, using any gc'ed language for these apps is going to be extremely rare for years if not decades. Seems far more likely that rust will chisel away at that market than golang or any other gc'ed language.
- nvarsj 8y agoMany HFT firms have used Java for ages. If you know what you’re doing you can avoid GC. Also, not everything needs to be realtime.
- haglin 8y agoFor arbitrage that must happen really fast, FPGAs is the way to go, and for complex code that needs to be rewritten often and quickly, Java is probably a better fit than C++.
- sangnoir 8y agoYou are right, but HFT is a tiny subset (headcount-wise) of the Financial industry.