|
Weeeelll, I'm definitely getting into dubious nitpick territory, but I'm not sure we can draw the conclusion that the JVM has negative overhead just because Java happens to be slower without it. That's mostly because Java wasn't designed to run without the JVM and, while you can do it, it kinda sucks. I think you have shown that Java is rather out of its element without the JVM, which is fair enough. Comparing performance with a performance focused systems language such as rust wouldn't be fair either, and the borrow checker is Def cheating compared to GC, so this is also not good grounds to conclude that the JVM has a positive overhead either. I think probably Go offers the fairer comparison, but my experience with it is so limited I can't really be sure. But unless I'm mistaken it's also GC'd, like Java, and runs without a VM, which is the difference we're trying to isolate. Ergonomics wise my understanding is they're comparable too, but like I said, I have very little experience with go. The performance analyses I've seen comparing the two seem to indicate a 10-15% performance increase in go compared to java, depending mostly on which report you read. It's definitely not clear-cut, I probably wouldn't put much weight to such an argument if it didn't align so well with my intuition. I'm not free of bias. Maybe I just want something different after nearly 15 years of Java? I mean I definitely do, but maybe it's affecting my judgment more than I think? But that's performance: the other limiting factor is that you need to install Java to run java apps(unless you go against nature and build sluggish native Java, but we covered that).I find I fairly often just don't want to have that requirement. Native executables have their charm, I find. |
The main difference is that rust drives the VM all the way to the point of generating machine code while java generates the machine code at runtime.
Rust does a translation of the syntax to a high level bytecode, then a mid level bytecode, then to LLVM IR, and finally it lets LLVM do the translation of the IR to machine code. The way LLVM uses "VM" is exactly the same way Java is using "VM".
Javascript is similar. In fact, v8, the engine that powers node and chrome, was initially written by Java hotspot developers.
The current performance initiatives that Python and Ruby are taking are doing exactly what the JVM and Javascript does. In fact, the pypy JIT and LuaJIT are learning from and implementing what the JVM does. It's a proven mechanism to getting more performance and better optimizations.
Even GCC does the same thing under the hood.
It really is clear cut, more than you might expect.