If you want the lowest software latency as in "latency arbitrage", then probably not. However, even in HFT industry, there are a lot of software that you want very low latency but would still trade a bit latency in exchange for much better productivity, maintainability, and especially robustness provided by the type system of Rust. You want to be fast, and also want to reduce the possibility of hitting a company-breaking bug in your billion turnover trading system.
How much slower would Rust be? If C++ delivers 4us and Java delivers 25us tick to trade for a particular strategy (say, book building, some calculations, then order sending), what could Rust get?
Theoretically, Rust can be as fast as C/C++ as long as you dive into unsafe when necessary, or skip string like UTF-8 string. However, a lot of the upside for using Rust will be gone as well, which will not make using Rust as compelling as in other domains. And when using Rust, people will probably incline to use more idiomatic Rust, which will be a bit slower. Thus I would say you would expect the actual Rust code you see will be to around 6us in scale, that is, a bit slower but still comparable to C/C++, at the same time with much better robustness (much fewer crashes).
There's some extra checks, which are usually branches, so I would guess that the branch predictor gets a little bit more pressured, while also taking a few extra cycles in the branches. But, I think you can still create fast happy paths with Rust just like other languages.
