The biggest one first: Operationally maintaining the JVM is a nightmare. It can be fast, but that isn't guaranteed and its not trivial to find out why, and easy for developers to mess up. It uses significantly more memory than anything else which will be your largest cost driver when running large services, compute is cheap, RAM is not.
Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software (given maybe only Flash beats the JVM in the history of boths existence) but the defaults for running a lot of things like groovy aren't secure (there is a debug port you can directly manipulate the memory of the running process without authentication). Commonly people use these debug ports in production, not just leave the defaults but actively choose to let them run. This is a very common pattern in Java based services usually caused by my first point. I am not aware of any other language or framework that offers remote memory access as a feature.
Then there are the dependencies and package ecosystem. I believe the "built on the JVM" languages like Kotlin have gotten a lot better at this, but as soon as you start tapping into the pure Java "enterprise grade" libraries you're most likely bringing in way more than you bargained for both in terms of complexity, maintainability, and security. A lot of those libraries are simply poorly built.
> 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.
> 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.
> 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.
> 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.
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.
Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software (given maybe only Flash beats the JVM in the history of boths existence) but the defaults for running a lot of things like groovy aren't secure (there is a debug port you can directly manipulate the memory of the running process without authentication). Commonly people use these debug ports in production, not just leave the defaults but actively choose to let them run. This is a very common pattern in Java based services usually caused by my first point. I am not aware of any other language or framework that offers remote memory access as a feature.
Then there are the dependencies and package ecosystem. I believe the "built on the JVM" languages like Kotlin have gotten a lot better at this, but as soon as you start tapping into the pure Java "enterprise grade" libraries you're most likely bringing in way more than you bargained for both in terms of complexity, maintainability, and security. A lot of those libraries are simply poorly built.