Comment by imtringued
5 hours ago
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets say 3-4 seconds), then the tests conclude practically instantly, in less than half a second.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
> In real world systems
A poet can beauty in any language.
They only consider programs that run for several hours. For short programs C is unbeatable.
> This is so untrue I still don't know how anyone can even claim this.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
> or if it consumes 2, 3, or 4x the memory
I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.
Yeah it's more of a concern but not "rewrite a ten year old application in Rust to save on the cost of several gigabytes of RAM" bad.
1 reply →