>There's no good technical reason for things to be that way
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.
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.
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.
I don't think compilers are a good example. The economics of software development has won a long time ago. For example in Gamedev with well known soft real-time requirements people (mostly) stopped doing that machine code dance many hardware generations ago. Like it happened with memory optimizations: people measure memory in GB now not in KB =)
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.
I understand that they are trying to say that it is getting better... 271 vulnerabilities is a lot. I have been using FF for a long time. I am now considering if using it at all was a mistake or not. And I think it was.
I have anecdata from my gamedev work that people tend to make mistakes when threads are pinned to some CPUs. Normally, when only time is a variable people can understand what can happen in their code. What confuses them is that space where those threads execute can be already taken. If a thread that should make whole system progress fails to grab a time slice these deadlocks are hard to reason about. Granted that lock ordering is the basic technique and if system did not had it all bets are off.
(Not a GP) I think you can see how poorly the string abstraction argument looks in context of a team-based project. Instead of dismissing it completely I would like to provide an example of a context where C is perfectly fine now.
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.
The only officially (at least partially) supported way from Microsoft is to add into Visual Studio the toolchain named "C++ Windows XP Support for VS 2017 (v141) tools". It is still there in the "individual components" of Visual Studio Installer for the latest VS but it is marked as [Deprecated]. It is a safe bet that MS will never fix any existing bugs in it or update it so at this point your best bet might be with the open source tools.
All other currently supported toolchains rely on runtimes that are explicitly not compatible with Win XP.
Given how embracing AI is an imperative in tech companies, "a link to something" is likely to be a product of LLM-assisted writing itself. Entire concept of checking through the internet becomes more and more recursive with every passing moment.
I am not sure if a slow pace is as beneficial as you say. I scrolled through the error handling issue brought up in this comment section ( https://github.com/ziglang/zig/issues/2647#issuecomment-2670... ) and its clear that only thing that happened there was communication on the issue was hindered. I come from C++ side and our "ISO C++ committee" language development process leaves a lot to be desired. Now look at error handling that they did passed in C++23 ( std::expected ). It raises some questions on how slow you can be while still appearing to be moving forward.
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 =)
Well the pool code fails to use char* type to write inside block of memory.
If you look at 'pool_free' code you can see that it receives used block from user as 'ptr' then casts it to 'Chunk pointer' and writes to into Chunk member value of type 'Chunk pointer'. I had to change that line to memcpy when I did it last time around 15 years ago in C++ with GCC 4.something. In short if you are writing your own allocators you need either to disable strict aliasing like Linux does or do the dance of 'memcpy' when you access memory as 'internal allocator structures' right after it was used as user type. When it happened to me write was reordered and I observed code that writes into Chunk* next executed first and write of zeros into user type second.
I want to make sure you understand that games as art genre and old resource limited and low level programs are far away from each other now. And moving in different directions at light speed. Unless one builds something that should be donated to a museum on release one does not need more of C++/SDL.
I say that as someone who keeps working as mostly C++ contributor into internal game engines for various projects.
I would want people to look forward and make works of art that expand what we thought was possible more instead of 'learning low level programming'.
As gamedev I came to love slow mutexes that do a lot of debug things in all 'developer' builds. Have debug names/IDs, track owners, report time spent in contention to profiler, report ownership changes to profiler...
People tend to structure concurrency differently and games came to some patterns to avoid locks. But they are hard to use and require programmer to restructure things. Most of the code starts as 'lets slap a lock here and try to pass the milestone'. Even fast locks will be unpredictably slow and will destroy realtime guarantees if there were any. They can be fast on average but the tail end is never going to go away. I don't want to be that guy who will come back to it chasing 'oh our game has hitches' but I am usually that guy.
Use slow locks people. The ones that show big red in profiler. Refactor them out when you see them being hit.
I know its a tall order. I can count people who know how to use profiler by fingers on AAA production. And it always like that no matter how many productions I see :)
ps. sorry for a rant. Please, continue good research into fast concurrency primitives and algorithms.
Modern malloc/free implementations must satisfy requirements such as being scalable. It eliminates any chance to implement blocking deallocation from non-owner threads. A modern implementation already has to be async in some ways. You can check paper behind Mimalloc for example.
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.