Not really, Java always had AOT compilers to native code, they just happened to be commercial and we all know how modern developers love to pay for their tools.

Java is very fast too ;)

Yup, Java is fast, but OP shared that Rust used 7 MB to do the same thing for which Java used 240 MB.

From looking at the traces, the performance difference between the two is minimal (on a per op basis). This mainly because both the Java and Rust services don't do much beyond interfacing with Redis/Tile38.

The impressive and important thing is the amount of resources used in performing their tasks. With a little math you can see that I have 64GB RAM, which is plenty. What remains scarce is CPU cycles, so if I can do more on the same machine; I'm happy.

Nice post. I will be really curious to see the same microservice done with Go and compare all of them.

My Go is very basic, but I can follow up with a Go impl and compare it with Rust. The code shouldn't take an experienced Go programmer more than an hour, as it's mainly mapping gRPC calls to Redis calls.

Please do. I'm interested as well.

Java is not statically compiles to machine code. It’s statically compiles to byte code which is hen interpreted or dynamically compiles to machine code.

So to way java is statically compiles is not quite correct in my opinion.

If you are talking about free Java compilers that is correct.

Most commercial compilers, specially those for embedded markets always had AOT native code as deployment option.

But now the bad Oracle is finally making the AOT compiler research they got from Sun Labs available for free.

At least one free Java compiler compiles to machine code: gcj.

https://gcc.gnu.org/wiki/GCJ

Yes, but it sadly died around 2009 when most developers left the project.

GCC devs just kept it around because of the unit tests, but with GCC 7 they removed it from the distribution.

How does it compare against c/c++ in terms of performance ?

Of course it is a bit slower, as Java does not take advantage of UB nor disabling security checks for the ultimate performance.

And depending on the use case there is always the issue of value vs reference types.

But it is good enough for most use cases of typical desktop software, to the point of Oracle's long term roadmap is to rewrite the remaining C++ parts of OpenJDK in Java (Project Metropolis), using a subset they are designing called System Java.

Also can check Android flagship devices (better for performance comparison), since Android 5.0, Java is also AOT compiled to native code. Although Android 7 changes it to a mix of interpreter written in Assembly, JIT and AOT with PGO. And Android P will introduce sharing of PGO metadata across devices via Play Store.

the native executables native-image generates are usually a bit slower than hot-spot JIT'ed code (~10% on average according to one article).

they do need much less RAM and startup time is _a lot_ lower though.

here it is: "Right now peak performance is a bit worse than HotSpot, but we don’t want to advertise that (and we want to fix it of course)."

http://www.graalvm.org/docs/reference-manual/aot-compilation...