Would finance apps be written in Rust today if all of the C++/Java applications weren't already written?
If anything Go is closer to fitting that bill, if only because of its traditional garbage collection. Applications written in Java by definition aren’t too concerned with memory management, and Rust is objectively a step backwards for them.
Rust is a more credible replacement for C++, but there I think it will be fighting inertia. Many C++ devs are actively against changing languages. I’ve also seen people “writing C++ in Rust”, using unsafe everywhere so they don’t have to figure out how to design their code to fit Rust’s model. You then end up with a kind of worst of both worlds.
The reason that such enormous software exists at banks is because the business rules are immensely complicated. All this code basically exists to deal with the complexity of the financial world, not the complexity of interacting with computers in a high performance way with correct semantics. In most cases performance is very secondary to being able to onboard programmers quickly to write oodles of code that can be modified rapidly to address changes in regulation or markets.
Java is good for this because it's a memory safe language, quite performant, super easy to learn (and quite common already) but also because you can abstract everything in a way that makes it possible to say, change the definition of currency exchange rates to account for new business rules without having to rewrite all the existing code.
Rust would require passing Box<dyn T> absolutely everywhere, at which points you are basically writing Java with extra steps. And I say this as someone who loves Rust and work primarily in Scala.
I only have a passing knowledge of Go so I can't comment on it's advantages or disadvantages much, although one of the great strengths of Go (tooling) is also very much a strength of Java (at least in large companies where there will be dev env teams that set up the Java environment for you.)
Often the law as written is ambiguous and your implementation is based on interpretation of a specific regulatory body, or even a single auditor, which frequently changes. In a country as heterogenous as the US, you don't have "business logic" per se, but just a bundle of jurisdictional exceptions, that all change out of sync with each other an incompatible ways. You often need to keep multiple implementations of the same ruleset active in your system for different products, based on when they were initiated as well. Any "changes" are actually only additions of complexity, you almost never get to remove anything.
None of these things are strictly unique to finance but they are pervasive concerns there. Codebases sprawl for other reasons too, certainly. But they necessarily sprawl for this one in finance.
Java and C++ are fine for what we do. What advantages (other than memory safety, which Java has too) do you see in Rust?
No crazy enforced OOP with a gazillion classes and inheritance, no non-sense design patterns just because the language enforces you to use OOP for everything, an amazing type system, no null pointer exceptions, great compiler error messages and so on...
Of course there are problems, like any other language, but it is crazy how it as a systems programming language is so good at expressing domain logic.
Java has a much bigger ecosystem, but judging JUST by the language design, I'd pick Rust over Java without thinking twice.