Earlier quoted context omitted.
> On Unity's case with some subsystems in the process of being replaced by HPC#. They are converting their C# code to HPC# which specifically does not do GC allocations. https://youtu.be/NF6kcNS6U80?t=886 HPC#: * no class types * no boxing * no GC allocation * not exceptions for control flow They are building a compiler to eliminate the GC from the GC'd language they were using.
Once upon a time, C code for games engines looked like this. void do_stuff(void) { asm { } } Hardly any C code in sight, and most of the stuff could equally have been coded in MASM/TASM with their higher level macros. Eventually game devs migrated to proper C. A couple of years later, C++ code in game engines, was not even "C with Classes", rather C compiled with C++ compiler. Eventually game devs migrated to proper…
And the game-industry as a whole is moving to data-oriented design, which tends to be hard to do at best (if not downright impossible) in most GC'd languages.
Regardless the transition from C to C++ has no performance cost (often a performance advatnage), so I'm not sure why you're bringing that up as some significant migration in this case? It doesn't support any argument for a transition from C++ to C# or similar, as that comes with a huge performance cost. Particularly in an era where CPU performance hasn't improved for almost a decade now.