The first three are not the deciding factors. Other platforms are still 10-100x more memory efficient even though they share the same disadvantages as the JVM.

Your fourth point is the primary reason.

The GC in the JVM is set to try to waste as much RAM as possible. If you tune the GC you can get a big improvement and the standard Java Frameworks are bloated and slow as hell.

In my opinion it's a platform that is bad by default and simply isn't worth using but companies don't care and just buy more RAM.

> Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves.

Just a small nit but the term you're looking for here is "value types". Rust does heap allocations(with the pointer overhead) via Box<T>, you just get explicit control over the overhead and cost.

Additionally things like Spring and dropwizard also add some overhead for better developer UX which rust doesn't have yet.

Spring is the new EJB. It's bloated and always amazes me on how complex it can get when you need to implement something not provided by Spring itself.

With Java 9 modularity and lightweight libraries like Guice you can get much nimbler apps.

Dagger is a more efficient, simple, debuggable design for DI, and I fully expect to see similar compile time code gen DI in Rust soon. (Adding ownership, mutability tracing, possible stack allocation, etc does make things a bit harder to get right in this arena.)

None of these are likely the reason - it should be as simple as Java's own managed heap preallocating that space.

5 times the memory is a serious exaggeration. At least twice, but no more than 3x.

The linked Wikipedia page references a OOPSLA 2005 paper by Matthew Hertz and Emery D. Berger that presents data saying that with 3x memory you might reasonably expect a 17% slowdown when compared to manual memory management. (And 70% slowdown when limited to 2x memory.)

Of course there have been some advanced in GC technology since 2005 (and that paper was deliberately measuring a relatively standard generational approach). But I don’t think I’d call the 5x figure a serious exaggeration.

Yes I've read the paper. Advances in CPU microarchitecture alone have noticeably shrunk that gap. There have also been significant algorithmic advances in GC. For instance, a few simple prefetching hints speed up marking easily by 30%, and parallel marking scales almost linearly with core count, to mention but two simple performance improvements.

So like I said, maybe in 2005 a 3x memory overhead only incurred 17% slowdown, but 3x overhead is at least at par, and possibly even a little ahead, of manual memory management.