Of course there is. What people gets presented is look how new graphics is shining. What devs get presented is look how much less manual work you need to get this graphics out of the door. Look at any UE5 presentation aiming at devs. You will be able to see a lot of 'just do this and technology will handle the rest of it'. There is no going back to manually making 3-5 replacements for each and every thing in the game. And the same goes for lights every few meters of a game world.

As a gamedev I don't really care about the regular software. You can see that the main problem for devs is to get paid for it. All kind of schemes with subscriptions and online services and such were tried. People just don't want to pay for the software. The mentality is 'we will get it for pennies on a sale' is the same like with the steam sales. Or even worse people will choose 'free' version with 'promotions' and data collection and whatever else that saves them pennies. Look at 'free to play games' steam category for the example of the horror show.

Oh and I don't think devs are the saints there. You can find a lots of examples that prey on gullible customers or trick people to buy 'digital goods' they don't need or outright bad things with gambling addictions and more.

The only thing consumer can do is to only vote with their wallet and push their representatives to regulate. The stop killing games is an example of the latter. The former is often deemed inefficient but Imho it is the only thing that will separate surviving studios and the shattered ones. As you may see in the press the names and past successes don't save studios from closing their doors now.

> 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.

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...

1. https://matklad.github.io/2025/04/19/things-zig-comptime-won...

I am sure programmers cherish every case when they can do micro optimization but in the retrospect the high level cuts is what made the system fit the perf or memory budget.

Build systems don't plan to converge in the future =)

Consider data compression library like Oodle. Even with closed source and use of dangerous things like multiple threads it is perfectly reasonable deal if game project's budget has money to be spent on performance.

The thing is if game project have money it is not likely to be interested in written in C game engines or core middleware libraries (like physics, sound or occlusion culling). Because after buying a license your team is still expected to work in that code even if official support is very active.

Disclaimer, I work in gamedev and never needed to touch C code.

All other currently supported toolchains rely on runtimes that are explicitly not compatible with Win XP.

Disclaimer: I would like to see Zig and other new languages to become a viable alternatives to C++ in Gamedev. But I understand that it might happen way after me retiring =)

I am both hands for faster -O1 build times though. Point taken.

Do you have any citations to support this 'safe release' theory? Like there are not many Zig applications and not many of them document their decisions. One i could find [1] does not mention safe anywhere.

1. https://ghostty.org/docs/install/build

Anecdata: A year or so ago I have been in discussion if beta features of C++20 on platforms are good to be used on large scale. It makes it not a sum but an intersection of partial implementations. Anyway it looked positive until we needed a pilot project to try. One of the projects came back with 'just flipping C++20 switch with no changes causes significant regression on build times'. After confirming it that it is indeed not an error on our side it was kinda obvious. Proportional increase of remote compilation cloud costs for few minor features is a 'no'. After a year the beta support is no longer beta but still partial on platforms and no improvements on build times in community. YMMV of course because gamedev mostly supports closed source platforms with closed set of build tools.

But ofc what can I know about browsers, I am just a gamedev. From my PoV (studio tech director) in custom game engines juniors mostly do acts of wanton destruction in the name of curiosity. And then leave for better compensated industries anyway.

In my opinion folks inciting random contributions from webdev crowd unfamiliar with C++ are not helping. And those who are familiar should know better than to do random drive-by features.

If thousands of HN readers suddenly decide that they need to start their 10+ years learning of C++ with immediate contribution to the Ladybird project it would be not really helpful, right?