> So you had to switch to C++ because Clojure / Java wasn't performant enough?
Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations.
It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and a more competent developer could have made it work.
But like almost all things if you chose a very out of the mainstream language and start to have issues, most developers will point fingers at the language first.
Side note, its a miracle that Jane Street kept using OCaml after the first few years and points to how strong their core tech team was.
C++ was an external dependency brought on by other systems that needed to be integrated and is a far safer language to use. I'd imagine that if you say HFT to most developers, their first thought would be C++ even if they haven't worked in the domain before.
It's like choosing Julia for your machine learning platform and then switching to python.
It's a shame you couldn't have pitched Common Lisp. Maybe could have ported your DSL pretty quickly and wound up having SBCL output nice compiled assembly instructions and shown x% speed improvement without much effort by using a "sister language" of sorts? ABCL in 2011 would have been a harder sell, it only had its 1.0 release that October.
A few years ago another commenter noted they had developed a trading system in Lisp and C https://news.ycombinator.com/item?id=25222297 (further comments elaborate a bit) before being asked to rewrite it in Java. What keeps less popular languages alive at companies, when there's no forcing reason to get rid of it like really unacceptable performance, is a conviction (borne out as far as I can tell) that it's ok to hire people who don't know the language -- they'll get up to speed more than fast enough.
> ... its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues...
Technically it can likely be done but in practice pushing Clojure code for performance (eg, [0]) doesn't follow the usual language idioms and relies on a sophisticated understanding of the interactions between program design, Clojure, the Clojure compiler and the JVM. I'd suggest pointing more at the language than the programmer. In a situation where direct memory management is required Clojure is a weaker choice.
Although in Clojure's defence it leverages immutability to squeeze out some surprising performance benefits without much effort. I would expect Clojure code to be fast by default but challenging to hand-optimise further if that extra level of control is required. Clojure makes it easy to write code that performs well, it is a stronger language for situations where ordinary business logic changes are the productivity bottleneck.
Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations.
It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and a more competent developer could have made it work.
But like almost all things if you chose a very out of the mainstream language and start to have issues, most developers will point fingers at the language first.
Side note, its a miracle that Jane Street kept using OCaml after the first few years and points to how strong their core tech team was.
C++ was an external dependency brought on by other systems that needed to be integrated and is a far safer language to use. I'd imagine that if you say HFT to most developers, their first thought would be C++ even if they haven't worked in the domain before.
It's like choosing Julia for your machine learning platform and then switching to python.