Memory and C++ Debugging at Electronic Arts [video]

This has been happening for a long time with Java HotSpot and Azul C4, which still represent the state of the art. Go isn't really doing anything new—it's still not generational, for example.

That is one reason. But if you watch OP's video, you'll see a lot of other reasons. In particular, games frequently have their own allocators & memory management. This is one reason why it might be hard, inconvenient, or impossible to use Java or C#.

That said, a lot of gameplay logic these days is actually written in a scripting language like Lua, and C++ is used for lower level systems like rendering & physics.

> In 2015, starting from scratch, where is C++ needed?

The main question is: "starting what"? For most web dev, you'd be crazy to start with C++. For the internals of a game engine, like unreal or unity or a competitor, C++ is probably the only sane choice. Also anything embedded. I guess Arduino & others are getting interpreters now, but C/C++ (notably minus the crazy kind of stuff in the video) is the easiest way to start.

I used to do hobby projects in C++, mainly graphics & image processing. My reasons were I knew it, it compiled to very fast code compared to anything else, and it was often the easiest way to interface with whatever open source libraries I needed.

These days most libraries are available in your favorite scripting language, and the performance can be good if you pay attention. I don't personally have a reason to use C++ anymore, even for hobby projects that need high performance.

1) Memory Fragmentation - why? This seems like it would only be a problem if they ran their entire game in the same virtual address space.

2) Subsystem A corrupting Subsystem B's RAM - once again, wouldn't one run the sim code in one address space, the rendering in another, etc. and have strategically shared pages for them to transfer data back and forth?

It really seems to me like the idea is 'yeah, we had virtual memory, and it was great, but we didn't really use it'... Granted, they put guard pages on some allocations, but that's akin to using supercomputer to solve your family budget. Lots of power available, but using it in a trivial way.

I acknowledge that there's some cost to a context switch, and that the 2005 generation used PowerPC with its fairly cache-inefficient hashed pagetable (poor locality), but the benefits of having a hard wall in memory between major system functions is immeasurable (I'm guessing that on PPC, they just set up a few Block Address Translation registers and called it 'good enough').

Then again, I come from a safety critical background .. we make aerospace code, so it's developed using the methods described in the article about 'the right stuff' that was up a day or two ago. We're really fond of having really hard walls between every resource we can (memory, CPU time, I/O bandwidth, FS bandwidth ... you name it) for major system functions. I realize that in game programming most of those walls aren't practical (due to performance impact) or necessary, but the memory one is fairly cheap and incredibly helpful.

PS - if you're wondering, we prevent memory leak problems by just disabling dynamic allocation post-boot, which happens on the ground. Our stack utilization is also required to be statically analyzable, which means that you can't do things like recursion. These limitations make the design of some algorithms extremely painful, but what other software have you ever heard of that can truthfully claim 0 memory leaks, guaranteed. We also do 100% code coverage (at the machine language level), 100% decision coverage, static and dynamic worst-case timing analysis, etc. etc. etc. Look up 'DO-178B' or 'DO-178C' if you're curious about what's done and why safety critical stuff is insanely expensive. More recently we're throwing in fuzzing for good measure, but fuzzing doesn't turn up a whole lot in extremely thoroughly tested code that's been reviewed line-by-line by dozens of engineers (and is subject to strict design limitations).