Comment by jorkadeen
3 days ago
The JVM is a state-of-the-art virtual machine with multiple open source implementations, a large ecosystem, and a fast JIT compiler that runs on most platforms. It is hard to find another VM with the same feature set and robust tooling.
I think the problem is that it targets a VM instead of native machine architectures, not the quality of the VM. I also find the times I need to target a VM to be very limited as I'm generally writing code for a specific platform, not a cross platform application. Of course this will vary between developers.
Targeting JVM means not having to roll your own garbage collector.
And bonus, you get a huge world of third party libraries you can work with.
It's been over a decade since I worked on the JVM, and Java is not my favourite language, but I don't get some people's hate on this topic. It strikes me as immature and "vibe" based rather than founded in genuine analysis around engineering needs.
The JVM gets you a JIT and GC with almost 30 years of engineering and fine tuning behind it and millions of eyes on it for bugs or performance issues.
I strongly agree. Java and JVM bytecode may not be our "cup of tea", but it is simply unrealistic to implement any runtime environment with comparable performance, security, robustness, and tooling. The only alternative is WASM, but they are not yet there feature-wise.
The JVM is a large and complex system with tons of configurable options. If you don't need it, why add all that cognitive overhead when you have perfectly good options that don't. And the benefits you gain are very limited if you aren't integrating with other JVM based systems.
1 reply →
The practical problems are slow startup time and high minimum memory usage. Since those are encountered early on in the developer experience, the reaction many have is predictable.
Yes… with a million weird environment variables that can affect your runtime.
Which is amazing, you can fine tune the performance of the runtime to your heart's content. Or you can just leave them as-is, the default behaviour is quite reasonable too.
So don't change them? Parent comment still applies to stock JVM.