Three things:

* 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.

* Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code.

* A tracing garbage collector needs about five times as much memory as explicit freeing to reach the same performance. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

* Like vegetarians, Rustaceans pay more attention to efficiency as a whole. This may give the appearance of Rust being more efficient, even if it's actually not.

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.

Java doesn't use system memory management by default, but rather keeps its own heap for garbage collection. If you start your java daemon with -Xms5000m -Xmx5000m then java will use 5GB of ram and use that to allocate new objects inside it. Depending on the garbage collector used, Java may wait until that 5GB is full before clearing it out, therefore using "up to 5GB of RAM" for the same 50MB dataset in a long running process.

It's not really a useful comparison for most uses of java though.

It's hard to say without really diving into that code. The 100x disparity seems pretty surprisingly high.

Often times people will give the JVM a sizeable heap in the interests of reducing garbage collector pressure (sometimes this is counterproductive). Usually it's possible to run with a much smaller heap, but we're still talking 100's of megabytes for most non-trivial apps. Even the VM itself will allocate a decent amount of memory besides that.

There's a number of reasons that typical JVM apps use more memory, but most of it seems to boil down to using the heap much more, lack of real value types (using the stack far less), and size overhead with small objects (see: https://www.javamex.com/tutorials/memory/object_memory_usage...).

It seems like the low cost cloud instances could be a real driver for the adoption of more lean runtimes. My client couldn't even consider those 256m/512m Heroku instances (with a large legacy JVM app).

Almost certainly either bad design (their Java app had a way bigger working set than their Rust one), or bad tuning (they set the heap needlessly large). Automatic memory management _does_ require more memory for reasonable performance, but you'd be talking about 2x or 3x the working set. Not 100x. Java objects will likely end up a little larger than Rust ones, but again not enough to make up the 100x difference.

Having a way-too-big heap is usually actively undesirable; you'll get fewer pauses, but much longer ones.

> or bad tuning (they set the heap needlessly large)

The claim "for equivalent Java code", might be slightly exaggerated, but looking at the claim as a whole: "Rust is Tilde's Competitive Advantage", "bad tuning" is part of the point.

"bad tuning" usually means "no tuning". Which means they spent the time they could have been tuning and used it to build features instead, or optimize their code instead.

From that perspective I wouldn't use "bad tuning" as an argument for continuing to use Java.

Oh, yeah, it's certainly a problem. However, they could almost certainly have done a lot better with Java than they'd been doing, if they wanted to.

If they increased the heap until the JVM was exactly as fast as their compiled Rust code on the same/equivalent hardware, you could get those numbers as some kinds of GC significantly decrease overhead with increased heap size.

With that said, that's an almost entirely useless benchmark, except as a testament to the amazing JIT compilation the JVM does. That the JVM with GC is capable of matching a compiled language specifically made to have efficient memory management at ANY heap size is positively astonishing!

Java has its own heap so the memory usage, certainly for a server VM, doesn't necessarily correspond to actual application memory use.

(Also, of course, your main server uses "up to" 5 GiB? That's fucking great. Until it goes beyond 64 GiB, who even cares. Work on something that has a worthwhile monetary return..)

Assuming it is heap space: that just prompts the question why is there heap space so large?

The default sizing policies optimize pause times, throughput and only as tertiary goal for footprint.

Additionally people often tune the JVM to avoid some startup costs which includes fixed heap sizes which prevents the JVM from returning memory to the OS.

On top of that there often are just plain bad programming practices like deserializing large files into memory instead of streaming them. I suspect that rust also attracts more performance-conscious developers that avoid such things. Or maybe it is applied in projects where "throw more hardware at it" is not a cost-effective measure and investing in more developer-hours is appropriate.

It answers the question: you can't just look at gross native memory usage and conclude the Java app is 100x less efficient, that value simply doesn't tell you a lot. Server VMs are commonly configured to use gigabytes of RAM from the get-go, and when the initial VM heap is full, Java will not make small adjustments but instead grab a big chunk, and when that is no longer needed, it is often reluctant to release that additional memory.

I have no doubt that a Rust app will generally be more memory-efficient, but ultimately for server applications that is really not something a lot of people care about because of the incredibly low cost of "just buying more".

I can believe it if the application is written properly using a functional paradigm to make it parallelizable. In Java this almost inevitably means making endless copies of objects to pass to functions and then immediately discard, except the discard isn't immediate. It doesn't happen until the garbage collector kicks in. So you end up with a memory use graph that looks like a sawtooth as the garbage collector is discarding hundreds of megabytes of temporary objects every time it runs.

I've seen this on a modded Minecraft server with a half dozen players connected. It would thrash over a gigabyte of memory every 5-10 seconds or so. I had to tweak the garbage collector to avoid performance hitches.

If I were to take a stab in the dark I'd guess optimized for latency by pre-caching everything under the Sun.

This most likely has to do with their respective memory models. Rust will try and allocate most things on the stack unless an item is explicitly wrapped in a Box. This isn't the only exception however. I can't speak to Java's model but I imagine it places more things on the heap.

Java caches the universe. ;)

(FWIW, it’s an apples-to-oranges comparison from a compilation, linking, packaging, etc. perspective, but from an end-user perspective I think it’s a reasonable claim.)

I call bullshit. Most probably their Java code was FUBAR.

> Most probably their Java code was FUBAR.

And so what? If a language's natural form leads to FUBAR code, what else is to blame?

Really? You can write FUBAR code in any language, language has nothing to do with this.

Of course you can. But if the same developers write performant code in one language, and something really slow in another, that's a mark against the second language. Maybe there's a tradeoff - maybe the slow codebase was written much faster, or something like that. But the kind of code a language makes you write is totally something you should judge it on.

Well i am quite experienced with Java and in my experience if they have this kind of ridiculous discrepancy in memory use, it implies they had a bad design or made bad choices. A rewrite in Java with sane choices would also end up with much better results. So I don't buy the "language is responsible" argument.

Nice false premise there. It could easily be caused by other things.