There is GraalVM but compilation takes a relatively long time even compared to a C++ project and as soon as you use features that it doesn't support it will fail to work which means you are stuck with Java because you don't want to risk using a language that doesn't officially support GraalVM (groovy kotlin etc).
You may be right that Java doesn't scale down well, but that's not normally the sort of work it's intended for. (Let's ignore the applets mistake.) It's a terrible solution for scripting, yes, but for heavyweight server roles I'd be surprised to see it significantly outperformed by .Net, and there's really no way Lua or Python would be able to compete.
OpenJDK has a very impressive (and heavyweight) JIT, for instance, and very impressive GCs of almost no use for short-lived applications.
With all that said, it'd be great if OpenJDK's new developments mature to the point that Java can become practical for 'lightweight work'.
so I think the biggest buck for the bang actual is dotnet (maybe go is as good as well, but does not really play in the same league). I think once valhalla hits the tables might change, but even than ReadOnlySpan<T> is way too awesume than just value types.
Python often leaks memory, the GC being built on top of reference counting to solve cycles, isn't compacting and can also be left disabled for performance, which is a trap. This is made worse by native libraries that also leak. It has gotten better, Python apps being one of the most deployed. But I haven't seen a Python app that's memory efficient yet, except for short lived shell scripts.
PHP uses tens of MB per request, which due to its "shared nothing" policy means you need several GBs of RAM for serving a Wordpress website that can withstand traffic spikes.
Many companies actually deploy their Ruby apps on top of the JVM, via JRuby, due to better memory usage.
Node.js is the only one that's more efficient out of this bunch, the GCs have similar implementations to the JVM and optimized for devices that are memory constrained, the problem being that Node.js processes are single threaded, so to distribute the load, you end up with multiple processes, plus due to JavaScript you also get more garbage.
> the biggest buck for the bang actual is dotnet
Not in my experience, but granted I haven't tested .NET Core yet.
Are there benchmarks for this?
Can you be more specific? What kind of workload and which JVM are you talking about?
I'm curious if you did any measurements and what you prefer instead.
The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side process, because you can actually do a lot in it, Java processes being able to be fat.
In my experience a well grown Java process will be much more efficient and predictable in terms of memory used than Node.js, PHP, Ruby, Python, at the very least.
The only problem I've experienced is the startup time, plus depending on use case I might prefer native binaries. GraalVM looks promising.
Scala.js is useful on the sever for example if you need to work with "serverless" tech, e.g. AWS Lambda, for which startup time is important.