For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.

It is more of generate more garbage / collect more garbage (Java) vs Not generating that much garbage in first place (Go).

This is use case for writing GC benchmarks developers not for typical enterprise CRUD developers.

It's definitely a factor, but it's not really enough. You can squeeze far more performance out of the hardware than idiomatic Java permits.

Sure, but not with another managed language like Go.

I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?

Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable to C, the reason for the performance discrepancy between the two is memory layout, which may or may not matter for the problem at hand.

In my experience, most (especially business) applications are absolutely not going through millions of data entries doing some local calculations over them, that part is delegated to a database. They either do some IO over them, or have much smaller element sizes.

Java has escape hatches even for handling some of the “millions-of-elements in a hot loop”, but for an AAA game engine it might not be the best choice, but for anything else? It is more than fair game.

Well I regularly do juggle millions of objects in Java. I'd estimate most Java application code is probably running at about a fifth the speed it could be. Modern computers are incredibly fast, but most of that speed is wasted copying data between representations and garbage collecting Stream API debris and boxed integers. Moreover, most Java applications using a database for storage do so in a dumb way that doesn't make good use of either the database or Java.

Well, as I mentioned there are escape hatches, but those come at a price in usually maintainability, e.g. using SoA, or external heap.

If you do have a million objects and it is indeed a performance bottleneck (as shown by the profiler) then it might be worthwhile to pursue these solutions, or even implementing them in another language. Noone claims that Java is for everything, but it is for most things.

I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.

Big part of why native interop is rare because it's slow and awful and generally not worth it.

I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.

FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example).

Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).

Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.

We'll see how far value objects and the vector API go. The lack of operator overloading makes writing scientific/numerical code a bit awkward, though this could be mitigated by using Kotlin instead.

Native interop is everywhere on Android, but then again, good luck having updated Java features on ART.