[eikenberry]

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.

[cmrdporcupine]

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.

[jorkadeen]

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.

[eikenberry]

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.

[vips7L]

You genuinely don’t need to think about any of the configurable options, especially if you’re running a client program. At most for server programs you just set the max memory percentage and soon you won’t have to do that.

[dontlaugh]

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.