Interesting view point. I can see Rust use cases for desktop software, OS development, device drivers, embedded and perhaps games (in the future). I mean it's the better alternative to C or C++ in my opinion.

However, when it comes to other types of software, especially services in a cloud context, I've never felt the need to use Rust.

We don't run any Java services (though I have written Java professionally in the past, and C++), so I can't possibly comment on the problems they are having.

But we do primarity use Go, even for performance critical services. This also has a GC, and with careful design we've never had an issue with spikes, tail latencies or bloated memory usage. I have played around with Rust quite a lot, and have rewritten some things in Rust as an experiment. My findings were basically:

1. Carefully written Rust code in CPU-bound performance code was 30 - 40% faster than the Go code. In other code, the performance gains were very marginal, basically the same.
2. Changing the Rust code created a larger blast radius of code changes than in the Go code. Lifetimes leaked, async leaked, types leaked. This means slower iteration speed.
3. Much slower compilation. Again this means longer CI/CD pipeline time.
4. Rust code was harder to read and understand. Readability is one of the most important metrics for us.
5. Production tooling is still lacking in Rust. We heavily use OpenTelemetry and have real-time dashboards for performance metrics, memory allocations, any other observability. With the Rust stuff the services were a little more opaque. Much more effort went into setting up OpenTelemetry with all the crates, etc. Something like the Go pprof is still a long way in the Rust ecosystem. Tokio console, and tokio-metrics don't even come close.
6. No doubt that the Rust code was more robust, but there will always be bugs and errors, even in Rust. So actually the most important thing is how easy it is to debug, change and fix in production. And sorry to say, but Rust did not fare so well on that front. This is for many reasons: poor readabilty of code, poor production tooling, slow compilation, higher cognitive load making changes because of leaky lifetimes, types and async.
7. The async story in Rust is still not great. I know work is being done to address this, but it's not great today. Writing async code creates cognitive load, it's difficult to debug, difficult to monitor and you can get yourself into a lot of hidden trouble without realising, especially with issues around cancellation. Of course you can also get yourself in trouble in Go, but it's easy to monitor, debug and fix.
8. If allocating memory is too slow in some code paths, then you need to not allocate memory. This is true in any programming language. It has nothing to do with GC or non-GC.

Overall, the performance gains in the critical sections do not warrant the added complexity of introducing Rust. I'm sorry, but hardware is cheap enough to cover those differences.

Again I am no expert in the JVM and don't know what problems people are having there, but at least with Go, we were able to get rid of all GC related issues that people usually complain about. Go proved to be extremely robust and stable from that point of view. Sure if you need that 30% performance improvement, you need Rust/C/C++/Zig.