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.
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.
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.
[0] https://blog.redplanetlabs.com/2020/09/02/clojure-faster/
Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language.
That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and HFT trading might very well be one!).
There are also languages which help you write much faster code, but on a higher level. Clojure transducers are a good example: pipelines built of composable transformations, where data sequences are not fully realized between the transformations. These can provide significant performance (and memory allocation) improvements, while still letting you write high-level code.