[inoop]

> Even my preferred IDE, the Jetbrains suite which I love, are resource hogs

Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?

Well then, given how much of a memory hog Chrome is, I guess we can all shitcan C/C++ as well.

Look, in any reasonable apples-to-apples comparison the JVM blows anything PHP has out of the water, including haxe, hiphop, etc.

And even if you write a PHP-to-bytecode compiler (e.g. https://github.com/jphp-group/jphp) then there are certain limitations to how fast and efficient any dynamically typed language can be. Look at all the shit V8 has to go through to do field lookups: https://v8.dev/blog/fast-properties

And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.

And if you really hate Java as a language, you can always use something like Kotlin.

[that_guy_iain]

> Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?

Actually, no. They said they didn't believe that.

> And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.

I think the point you need to specifically define that the JVM needs to be well tuned kinda shows you know there is a grain of truth to the fact that you dislike so much.

And really comparing performance of a compiled language to an interpreted language is kinda cheating. Compiled should be faster.

From my experience I can run a Go application with the same performance requirements as a JVM application with less resources. For example, for the same requirements I had 50mb of ram assigned to a Go docker and 250 mb assigned to the JVM. I'm sure we all agree 250MB is not so much but that adds up. Then we get on to the fact it's quite common in the real-world to see lots of apps built on the JVM needing lots of resources, sure you can say that's the devs problem and if they just did it properly it wouldn't be the case but if so many people are doing it wrong then maybe it's being the JVM makes doing it wrong so easy. (Which was PHP's problem so many years ago)

[inoop]

> the JVM needs to be well tuned

You don't need to tune it to beat the pants out of a PHP-based solution.

Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

[that_guy_iain]

> Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

No, if I've worked at a shop with a large scale low latency PHP app, they aren't not bothering their ass with Java, no need. They clearly have a highly comptent dev team who know their tools.

The only time I've dealt with Java is when companies are moving away from Java because their Java app is bloated beyond hell. They have a dev team that aren't highly comptent and think switching languages will help.

If I was dealing with the two, I would most certainly expect the Java one to handle scale better. But if I'm at lower level scale I would expect the PHP one to require less resources. Once PHP starts to scale up it can be a resource hog.

The reality is the comptency level of your dev team is the most important thing.

A think you need to remember, the JVM can scale massively well but the majority of systems don't need to scale well.