4 ms·
I've heard that attitude before. C++ developers working in finance around 2000. They were damn sure that no-one was going to switch to any other language becaus
by marcus_holmes 8y ago
I've heard that attitude before. C++ developers working in finance around 2000. They were damn sure that no-one was going to switch to any other language because reasons.
I'm sure there's still a bunch of C++ devs working in finance, and making decent money, but I think the industry has moved on now.
The industry always moves on
- DaiPlusPlus 8y agoHFT 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.