Hacker News
points by switchbak 10 hours ago | 0 comments
I spent a couple weeks trying to bolt this on to our setup to support a more serverless style approach. OpenJ9 (sadly) really didn't work out well, perhaps we run in a way they don't optimize for. Azul and OpenJDK's approaches helped - but it is quite intrusive (you need a profiling run), and the absolute benefits aren't that great. It's mostly doing classpath stuff at present, and not really AOT work on machine code (though that is in the pipeline).

All in all, I wasn't particularly impressed with the outcome. Obviously GraalVM has more headroom, but that's an even more intrusive change.

When compared with a Rust port of our service, the delta of the efforts is absolutely astronomical. Ridiculous performance, near-instant startup, radically less memory consumption. I mean - duh - but nonetheless, when I contrast the effort vs payback, it's very hard for me to want to invest so much in techniques that have so little payback (graal) when I can put that into an approach that leaves me in a much better place long-term.

If I had mountains of legacy, obviously I couldn't do that, but in my situation it seems like a much more attractive option.

[–] sideeffffect 8 hours ago
> Ridiculous performance, near-instant startup, radically less memory consumption.

It seems like your use case is rather not a good fit for Java.

Java shines best with large applications, where more abstract source code is desired and when you care more about typical performance, not the worst case performance. And if you can afford the cost of all those benefits, which is higher RAM usage.

At least that's the theory :)

[–] ahartmetz 1 hour ago
It's not like typical performance of Java is great and only GC pauses (or whatever) drag it down. In other words, Java is no match for Rust / C / C++ even comparing "good runs only" of both.