As an HFT programmer I like this article because it means less competition for me.
I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.
Having done both I agree with you. I find it's harder to write non idiomatic code that pretends to be another language than to just spend the time learning that other language.
But I get why people might feel it's worth a try, cpp probably looks more daunting than any other language to a novice. There's a lot of concepts to be mastered before you can write decent cpp, where in a lot of languages you can get started and discover things later. With cpp the abstraction gets very detailed. You might not even care what the difference between stack and heap, value or reference passing is in other languages.
Eg you can write python pretty intuitively and get a hash table as part of the language. If you're writing cpp you need to know how types work, how templates work, and how the STL containers work (allocators, traits, constness etc) just to save a simple hash table.
I recall listening to a recent interview with
Chris Lattner who said the more languages you learn the faster it is to pick up others because of the overlaps.
Working in other languages, the idea of references and values didn't kick in to me, that is until I learned basic C++. I think it's because C++ engineers (well, the ones I would watch anyway) were sticklers for performance and so they'd describe the subtle differences in implementation. Even though I don't code C++ anymore, using it for a short time really helped to develop a better understanding of how code actually works.
The question is how much of your remaining tick-to-trade is really in the software loop. Realistically at the bleeding edge more and more logic is going into FPGA (and maybe ASIC t some extent). Your software is primarily there to make sure that you've processed the previous tick and re-configured the FPGA rather than actually competing in tick to trade. Given that's the case the software doesn't need to be the fastest, it just needs to be fast enough.
Meanwhile if your logic isn't going into FPGA you may well just not be super competitive anyway and therefore the priority is time to market.
+1, that's how things typically work these days. Note that "processing previous tick" may take a very-very long time (up to fractions of a millisecond) to execute, in which case you still want that part to be as fast as possible.
As an HFT developer myself I have to disagree. I worked for tier 1 banks that used both:java and cpp.
The trend is moving towards quicker time to market and simpler implementations and replacing cpp with java.
The cpp code bases I had to deal with were old, hard to maintain and easy to break.
More often than not cpp was a pretty bad lock in as well. For example a big evil bank very well known here struggled for 3 years to upgrade the compiler on one of those projects.
Did not happen to this day, I'm told. Few years later they are still on RHEL6 and gcc 4.
Speed is an important factor in this business, but so is time-to-market.
I am afraid tier 1 banks aren't tier 1 in HFT though. Best HFTs are at "small" houses and your tier 1 bank experience isn't reflective of what they do.
How is replacing with Java better than replacing with C++? Legacy code is a problem, and bad programmers will write bad code in any language. If you need to start over does Java give you anything you can't get with modern C++?
From my personal experience I'd say java is much more forgiving than c/cpp and things like debugging or dependency management make it a tempting option in a time-constrained environment.
It depends on what the edge is. Presumably you're competing for a sub 3us edge but they're not all like that. For slower edges Java might be a better idea.
The one thing C++ can do better than C is inline a pipeline of operations using templates/type strictness which is handy for compiling all the (socket -> feed decoding -> book -> model) permutations without some macro trickery.
I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.