>what technology you choose depends on what you value

No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use.

In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment.

>It doesn't make programs better

Yes it does. With a GC you lose control over runtime, which is crucial to the performance.

I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.

>No, what technology you choose depends first and foremost on what you want to achieve.

Maybe for you. But not for me. I find the rest of your post to be very mean spirited.

I don't work in the games industry because those constraints sound miserable.

First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.

However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.

It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.

It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.

Even if there was entirely non-stop GC (e.g. through reference counting) it's still wouldn't be a good choice for games since a game is, essentially, just a neatly arranged data structure in memory. Compared to the amount of memory a game reads/writes every frame all other I/O channels are just noise. You actually want to manage your memory instead of trying to figure out how to force a foreign memory system to do what is best.

Some of the work done to work around GC feels similar to the work you'd do in C/C++ to work around memory fragmentation issues. Also, depending on the language/runtime, you might be able to influence the GC algorithm, or at least the frequency with which it runs. If you can e.g. run a GC every second for not longer than ~1 frame, then pauses won't be noticeable.

A dropped frame is always noticable. What you can do is keep a budget for GC and then force-collect every frame.

Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.

I've spent enough time writing C to know that I want to minimize my time spent writing C. It's been an important language to know for dealing with foreign function interfaces, but I work almost exclusively in high-level, memory safe languages now. I'm much happier and my programs are much less vulnerable to exploitation.

I think C is pleasing because the program does nothing that you don't explicitly tell it to do, and because just about everything that you can tell it to do maps clean(ish)ly down to the machine language that implements the equivalent code. It's possible to know exactly what's going on, and when.