[imtringued]

I'm not sure I understand what exactly you're talking about. I personally moved away from Java to Rust, because of the obvious and immediate performance benefits and this is possible because Rust manages to stay safe despite the lack of a garbage collector.

[SleepyMyroslav]

I am not GP poster. I find pron points interesting even if I work in the gamedev on game engines. If you don't mind I will try to explain how I see them interesting. Since I have not worked on Rust systems I will stick to C++.

Note his example elsewhere in this discussion of 2 projects done at same time in Java and Rust and the complaint that Rust system used too many locks. This can happen in C++ too. But why it does not happen in (my) practice? Because C++ evolved to not use locks in large scale parallel systems. This was said from mainstage conferences keynotes at least since 2013 [1]. So there is "normal C++" and "C++ that works at large scale" and they are not the same C++ languages. The performance scales between them are many orders of magnitude. Imho it does not mean that Java anywhere near the best of what C++ can do. So here we are talking past each other. pron is correct that Java is not bad and you are correct that you have no reasons to leave Rust.

1. https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-se...

[pron]

> The performance scales between them are many orders of magnitude. Imho it does not mean that Java anywhere near the best of what C++ can do.

I don't think you're aware of where Java is today. Here's a recent talk about some of the issues we're working on now: https://youtu.be/J4O5h3xpIY8

I said that in the past the people who believed Java can't match or exceed C++'s performance were typically those with a lot of low-level programming experience and little or no experience with Java, while today it's mostly people with little experience with low-level programming, but I think you may be in the first group. To people in that group, the question I pose is: what is exactly that you'd think makes Java harder to compile in an optimised way than C++? That's not hard to answer for JS or Python, but you'll find that it is hard to answer for Java. (I don't have a question to ask the people in the second group because they are typically people who don't know much about software performance to begin with, don't have any informed intuition about it, and just say nonsensical things like "runtime overhead").

On the whole, the range of optimisations available to our compiler is larger than to a C++ compiler, and we have a wider selection of memory management optimisations, too (this matters mostly in large programs with a wide variety of object lifetimes).

So if you were to ask me why I would speculate that C++ can't be as well-optimised as Java, I could tell you that it's because it can't inline as aggressively and it can't move pointers (due to its constraints and intended domains).

I think an answer for why Java wouldn't be as optimised at C++ could refer to things like "Java has an interpreter" (true, but that design was chosen to support more aggressive speculative optimisations in the compiler), or "Java has moving-tracing GCs" (true, and that was chosen because they offer an optimisation of memory management in a wide variety of situations). The JVM was designed to address specific performance shortcoming of low-level languages; true, they don't result in a win in all situations, and in some they even lose, but these mechanisms were chosen because they do win in many situations.

In general, when we (the JVM's developers) see something that C++ can do faster, we treat it as a performance bug and solve it. What John (the chief JVM architect) is talking about is related to the last area where Java suffers (arrays-of-structs) to which we'll start delivering the solution very soon.

There are some intentional performance-related tradeoffs that both our team and the C++/gcc/LLVM teams make, but they are about offering better or worse performance under different circumstances, and definitely not universally.

As an example I was personally involved with, the C++ team and us intentionally chose differenet approaches to coroutines that give better performance in some situations and worse in others, and we both opted to prioritise different situations (i.e. situations where cache misses are more or less likely).

In general, C++ offers better performance than Java in some programs, and the opposite is true in other programs. On average, their performance has come closer over the years, each improving the areas where they were weaker.

As to "the best of what C++ can do", it's hard to define, because, as I said, every Java program can be seen as a C++ program, so technically C++ can always match the performance of a Java program given enough effort and expertise. But when talking about performance, what's practically possible matters much more than what's hypothetically possible, and in those programs where Java wins, achieving the same performance in C++ is just far more costly.

But also, given that both languages can and do come close to the maximal hypothetical hardware performance, they're rarely too far apart (unless we're considering warmup time), and they're both very much "anywhere near" each other almost all the time.

[SleepyMyroslav]

as for my experience, yep I do not have Java experience and a long list of C++ projects.

> what is exactly that you'd think makes Java harder to compile in an optimised way than C++?

In games C++ is doing some simulations and data delivery for GPU. Code that does work on GPU is not mixed with rest of C++ code. So invoking Cuda (or the likes) in the middle of computation is a cheat code that Java does not have. Simulations on the CPU need to be efficiently parallel ( think 12 hardware threads for last gen or 4-6 threads for smaller platforms) and most likely specialized for hardware SIMD ( think AVX2 for last gen or SSE2 like for smaller platforms). To wrangle multi GB data efficiently a lot of compression/decompression and data structures are needed. Does Java still has overhead per class instance? It might force designs with arrays of primitive data types that are more verbose.

Add there per platform I/O and everything. It means that games force people to unlearn everything that language ever thought about standard I/O. Even more about being cross platform. In C++ it means something completely different. In C++ you can't trust language implementation vendor with anything. From your comment I assume that Java teams rely on language implementation in lots of ways. In C++ being efficient means do it yourself. How efficient our memory allocation is? Answer can only be per engine/project. There is no 'average' because 'vendor provided' is the bottom of the barrel quality. No one is improving vendor provided exactly because no one is expected to use it.

In short there are hard to compare many different C++. I can't see them compare to each other much less to other programming languages like Java. This might be not the answer you wanted but that's all I have.

[pron]

> So invoking Cuda (or the likes) in the middle of computation is a cheat code that Java does not have.

It does (and has since JDK 22). But what we're working on now is JIT-compiling Java code to CUDA (not arbitrary code, but certainly code that's suitable for a kernel): https://openjdk.org/projects/babylon/articles/hat-matmul/hat...

> and most likely specialized for hardware SIMD ( think AVX2 for last gen or SSE2 like for smaller platforms)

Yep, we've had good SIMD support for a few years now. (https://javapro.io/2026/04/09/java-vector-api-faster-vector-...)

> Does Java still has overhead per class instance? It might force designs with arrays of primitive data types that are more verbose.

That is the last area where Java is still behind but the work on arrays-of-structs (with no headers) is nearly complete. A first release of that is imminent.

> In C++ being efficient means do it yourself

Right, and that's precisely what I meant about low-level languages being optimised for control and not performance. You could do things at such a low level in Java, but the main problem is not the performance but that it's just less convenient than in C++.

Anyway, aside from some outdated (or soon-to-be-outdated) things, what you pointed out is mostly about lack of convenient direct low-level control rather than general performance, and that is exactly when low-level languages can be a better fit.