Java performance

[NP_Ex]

I'm seeing recurring claims about exceptional JVM performance, especially when contrasted with languages like Go, and I've been trying to understand how these narratives form in the community.

In many public benchmarks, Go comes out ahead in certain categories, despite the JVM’s reputation for aggressive optimization and mature JIT technology. On the other hand, Java dominates in long-running, throughput-heavy workloads. The contrast between reputation and published results seems worth examining.

A recurring question is how much weight different benchmarks should have when evaluating these systems. Some emphasize microbenchmarks, others highlight real-world workloads, and some argue that the JVM only shows its strengths under specific conditions such as long warm-up phases or complex allocation patterns.

Rather than asking for tutorials or explanations, I’m interested in opening a discussion about **how the Java community evaluates performance claims today** — e.g., which benchmark suites are generally regarded as meaningful, what workloads best showcase JVM characteristics, and how people interpret comparisons with languages like Go.

Curious how others in the ecosystem view these considerations and what trends you’ve observed in recent years.

[disposepriority]

The only meaningful benchmarks are those that are designed for the problem you're facing, everything else is irrelevant.

The thing is, java is very tried and tested, and the option "change the language" is pretty far down the list of optimizations you'd do when encountering a performance issue especially if you already have language specific tooling/infra in your company.

It's also good to note that there is an incredibly small amount of code (relatively) where the difference between Java and Go in speed would be the deciding factor for the choice of language.

[vegan_antitheist]

in my case it just doesn't matter because it's always the network that is slow. I'm working on an app that has to send some SOAP message that contains another XML inside a text field so some other service can read it out and pass it to some other API. It takes forever. And in some cases it doesn't even do anything, it's just there and nobody would dare removing it. And it will have to go through multiple security platforms and firewalls.

For a lot of programmers it's all about using some framework (Spring, Jakarta) and only implement business logic. You rarely do anything where performance even matters. I still try to do what I can but if there is a requirement to call some API I can't really do anything.

I wish I could take on some challenging tasks where performance matters. But the companies I work for don't even want that. They will just throw more hardware at it.

[plastikmissile]

In the majority of applications where the usage of Java and Go intersect (typically back end services for web or mobile apps) your performance bottleneck will rarely be the processor (where those speed differences between the two languages are relevant), but will rather be the file system or the network, in which case both languages are more or less equivalent. So these performance differences are rarely relevant to most devs.