I think there are a number of disenfranchised "close to the metal" programmers. C has stagnated and won't likely move much, C++(++++...) has reached bonkers level of complexity, D is... D who, and Rust is highly opinionated, which is a double edge sword.
Rust is complicated by its very strict memory safety. While that's nice, I don't think memory safety is game developers #1 priority. A crash is annoying but acceptable.
Zig also doesn't assume a global allocator anywhere (malloc/free), and I think game developers often like to use custom allocators for performance reasons.
There's more extreme situations like Super Mario Land 2 for the Game boy where it's possible for the game to present it's own memory on the screen and if you understand how it works you can do things like ask the game to execute the ending sequence [0]. At it's most extreme a series of TASes was presented in 2017 wherein multiple different hardware systems were linked together via RCEs in different games to make a VOIP streaming setup from a bunch of consoles that don't actually have internet connections [1].
I'm sure there's all kinds of reasons this kind of UB is undesirable, and could be hazardous in some environments, but people have also done some really cool stuff with it!
[0]: https://www.youtube.com/watch?v=faiZgO35YaQ&t=0s [1]: https://www.youtube.com/watch?v=7CgXvIuZR40
It has and it has not. It can offer level of complexity matching that of a programmer. One does not have to start coding concepts as the introductory course to programming. Take some numbers stuff them into array, sort and print - is a simple piece of cake anyone can grasp.
The only thing stagnant on WG14 is their regard towards providing safer string, vector types and enumerations.
It of course has to remain with us due to the insane amount of code already written with it and some tooling (and eg for verification certain subsets of C), but it is not any closer to metal than other system programming languages, the “standard lib” is full of foot guns, it has a very weak type system, it has no way of enforcing basically anything. Also, due to the its lack of expressivity it relies on text-based macros (and those I hate with a passion, as there is hardly anything worse than text-replacing source code with no knowledge of syntactic elements).
To me, C is the easiest way to interface with the platforms that I develop for. It's also totally sufficient to implement the ideas that I'm working on - figuring out the data layout, the flow of code and data... It offers a concise syntax for the frequent operations - load / store, arithmetic, dereferences, and function calls. Most languages are already disqualified by not offering or discouraging nesting of data types a.k.a value types, making it way too complicated to simply copy data "anonymously", using memcpy() or similar.
Think about that - the language that people can't stop bitching about because it doesn't offer "generics" is actually the one that allows you to read and write data generically without a tremendous amount of complexity and/or slowness.
That's why my personal route is to learn ways to not need the type based polymorphism offered by more complicated languages, and to get along with just straight code that can push _any_ data payload (type) to the next endpoint - without requiring the multiplication of junk in the type system and/or in the compiled binary.
Macros aren't used that much but they would be missed a lot if they weren't there to help in some cases where we need to hack an abstraction over (lexical) syntax instead of data. I said above that you can't abstract over languages' syntax, and C macros don't really do that... They're a hack, and sometimes tremendously useful.
https://floooh.github.io/2018/06/02/one-year-of-c.html
...and "modern C" is often misunderstood by C++ people who only know the fork of C known as the "common C/C++ subset" (which is basically an outdated, non-standard dialect of C that's stuck in the mid-90s):
https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
However, I'm hoping to eventually abandon C in favour of Zig within the next 10 years or so :)
C is the lowest common denominator. It has good compilers that just work, with no drama or surprises. It's portable across CPUs and operating systems. It will continue to work for all Unix-like platforms long after trendier alternatives have turned to dust.
It has good code formatters and analyzers. It's an easy language to completely understand, and it's easy to read if I don't try to get to clever with macros or type tricks.
I don't have to remember whether ${language_feature} is Considered Harmful yet, like C++ or Rust where the current best practices constantly become Bad Code in favor of the next trendy feature.
The C ABI is the standard for libraries on Unix-likes, and I usually want to use a couple of special-purpose libraries. Calling libraries requires no wrappers, FFIs, or anything else.
Yes, C has limitations. Lots of them. But it also has an enduring momentum that's not going away any time soon.
I wrote a firmware recently for low power microcontroller. No memory allocations in code. The language is simple and easy to read unless one is purposely trying to be fancy. It is very performant - the end result and compile steps as well. And there are megatons of C libs for microcontrollers. Would not dream of using anything else for this particular task
Sure let WG invest their efforts where needed but for my own case I do not care.