What does that have to do with being "closer to the metal"?
Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing.
Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction.
You also asked what the advantage of golang was and I told you what the advantage was. I'm was not saying "closer to the metal" is the right description, but, if we'd stop being pedantic, I think we know what she/he meant.
Some people really don't want to tune VMs. No one is saying Java doesn't have a place too. Jeez, dude.
OK -- but you've listed a whole bunch of third party projects and technologies and tools to get Java closer to what Go does _really_ easily out of the box.
I like Java (used to _love_ it about 26 years ago... been a decade since I've written any) but Go is actually a breath of fresh air for typical cross-platform systems programs.
Golang + UI should have trash JDK to the trash of the history long ago, but people never learns, they are blinded by the Enterprisitis.
Ironically Sun invented Java because lots of people bitched against TCL's non GPL license. Ironically, TCL/TK since 8.4 ran much snappier and faster than any Java turd even in 2004. Even simple Java 2D indie games looked laggish against AMSN, which was a "biggie" TCL/TK MSN clone back in he day.
Ahh, Golang UI stuff... now that is a dark alleyway!
But I think Java comes from something rather older, designed for interactive television, way back before anyone outside CERN had really seen a web browser. In that way the JavaStation is philosophically much closer to the roots of Java than the Java applet.
What are those Java framework turds like Quarkus, that you keep bringing again and again?
Also GraalVM is not 3rd party but also not OpenJDK. It is Oracle product and where many perf related features are only in enterprise version. Also it does not support most of JFR JVM monitoring.
I am perfectly fine people/companies paying for performance. But it is not like Native image is trivially applied to any existing Java project. Either one has to use limited frameworks that you keep listing or spend endless hours in generating native json files to cover reflection cases.
Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing.
Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction.
[1] https://quarkus.io/ [2] https://micronaut.io/