Given that automated trading systems are in fierce competition between each other, and thus have a never-ending thirst for tiny performance advantages, maybe the JVM with its emphasis on abstract high-level language constructs and runtime safety isn't the best platform and shouldn't bend itself into unnatural contortions to satisfy this niche?

We've got Rust now, offering both low-level control and safety. No need to take the SUV on the racing track, it is not at home there.

I’m unaware of HFT systems running entirely on a JVM. Do you know of such cases? Safe Rust isn’t fast enough for HFT in my opinion. What kind of HFT?

Amusingly, though somewhat tangential, I observed a rather simple Go implementation (nothing fancy, ordinary channel bound message passing) outperform a fairly sophisticated Rust implementation for the same logic when we were toying with a prototype. But that was at an IO boundary. There are many other variables of course, but an amusing anecdote to share.

Yes, Java is often used in HFT, due to one being able to quickly modify the algorithm, while keeping it safe and performant. This is used for mostly the algorithms that have to be fast, but not to the degree of “let’s buy this building which is closer to the bank, because the internet cable length matters”. Do note, that for the latter kind, general purpose CPUs (and thus, programming languages) themselves are not fast enough and is dominated by ASICs.

"Why we chose Java for our High-Frequency Trading application"

https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

LMAX Disruptor customers

https://lmax-exchange.github.io/disruptor/

Among many other examples.

Much appreciated indeed. Though I’m unconvinced by that particular piece on Medium. There’s no mention of their purported trading workloads, reads rather like a pile of SEO keywords spiced up by a couple charts and appears more like an attempted product placement for Azul Zing instead of HotSpot Zulu or other distributions. The author doesn’t seem to associate with finance either. I know Disruptor fairly well, it’s been underwhelming.

> I know Disruptor fairly well, it’s been underwhelming.

The newer, better thing from the same author is aeron.

I will not pretend to have any inside information, I just picked up some of the related discussions on HN over the years.

I'll easily believe that it can take significant work to outperform Golang (or Java) in Rust where application complexity is high (not just a simple cmd app), they do have an excellent baseline out of the box.

Definitely, microbenchmarks are what’s most striking especially because they seem immediately approachable, as opposed to a full fledged app with a variety of integrations. In that case the quality of the dependencies is much more important to me than any benchmark runs. Great point, totally agreed.

I personally am often quite astonished by the amazing performance Go apps squeeze out of the box, with many efficiency tweaks and tricks we way too often take for granted, which you need to be aware of to come by in C++, Rust, or even Java. But I do also often get disappointed by the sudden inconsistency of that performance in Go after a while, the variance is a bit high, with C++, Rust, and Java runtime behavior being very consistent in general.