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.
I haven't used the JVM in a long time, but judging by the web framework benchmarks I've checked out this morning e.g. [0], it seems like there are many Go frameworks that beat those on the JVM.
I agree with other commenters on this thread that in general such benchmarks may not mean a lot when compute is so cheap and the autoscaling infrastructure is awesome, but I often work on embedded platforms or other resource constrained devices where adding the JVM is a nonstarter (not that Django or Rails is an option either in those cases).
Note that those benchmarks use a non-standard golang HTTP library (fasthttp I believe), which even according to it's author makes certain compromises and can be tricky to deal with, and can fail in edge cases (I'd avoid it for production). Whereas the Java versions are much more standard and safer to use.
Secondly, something seems off if a php framework is getting top place, unless it's doing some AOT compilation.
TrueDuality|5 years ago
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.
apta|5 years ago
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.
_huayra_|5 years ago
I agree with other commenters on this thread that in general such benchmarks may not mean a lot when compute is so cheap and the autoscaling infrastructure is awesome, but I often work on embedded platforms or other resource constrained devices where adding the JVM is a nonstarter (not that Django or Rails is an option either in those cases).
[0] https://github.com/the-benchmarker/web-frameworks
apta|5 years ago
Secondly, something seems off if a php framework is getting top place, unless it's doing some AOT compilation.