[apta]

> Operationally maintaining the JVM is a nightmare

The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that. Secondly, with new GCs like ZGC and Shenandoah, the number of knobs to tune (at least with respect to the GC) has decreased dramatically to only a couple.

> Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software

This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore.

[TrueDuality]

> The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that.

That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world. The fact that you need to know at least 16 flags for the JVM with obscure syntaxes to get a basically stable Tomcat server (not Tomcat flags, those are another nightmare) is precisely the problem with Java.

> This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore

You've got to be trolling on this one. I'm definitely not talking about browser-side rendering. Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.

[apta]

> That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world.

This is just hyperbole and you know it. The JVM with the turn of a few knobs is able to accommodate high throughput batch workloads, as well as lower latency workloads, especially with the advent of ZGC and Shenandoah, all while supporting multi-TB heap sizes.

Look at what hacks the Discord and Twitch teams had to endure to get around golang's workload specific GC for example, and it will show why the JVM is written the way it is.

> Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.

Those were not JVM-specific issues, and would have happened regardless in any hosting environment or even compiler if we're talking about running single binaries. You need a good upgrade path process laid out.

[nobleach]

> The JVM gives you practically every knob you need to achieve maximal performance

While this is true, finding folks that deeply understand how those knobs work, (and what the potential pitfalls are of twisting each knob might be) is not as easy as finding a Java/Kotlin/Scala/Clojure/JRuby developer. The out-of-the-box JVM experience can take one quite a long way. It's that last mile to real performance that can be the nightmare.

[apta]

Well, you need operations people and people with experience anyway. We've seen the blog posts by companies like Discord and others that needed to implement difficult workarounds in their golang code bases. The problem is always there, not thinking about it won't make it go away. I'd argue that golang "solution" was a big hack, and that having a proper mature solution like the JVM would have saved time and effort.