I would argue that there is less mental burden, if you stay within some simple limits. C has a lot of complexity if you push its limits, mainly because it is so old and the limits have been pushed in ways they havent in other languages. C has to run on very strange platforms and has many many implementations, and so much code depending on it. This makes it very hard to maintain. If two large C compilers do things slightly different and very important software depends on those behaviours, then its very hard to make a "Clean" fix without breaking lots of software.

The argument against "Why dont they just fix X?" usualy commes down to: it would break millions of lines of code, make every C tutorial/book obsolete and force millions of C programmers to learn new things, not to mention that if we broke the ABI, we would break almost every other language since they depend on Cs stable ABI. Breaking C would literaly cost tens if not hundreds of billions of dollars for the industry.

Look at the move between Python 2 and 3. The cost of breaking bakwards compatibility have probably been astonomical, and then there is way less Pyton code being maintained then C code.

C operates on a scale that is almost unfathomable. A 1% perfomance degredation, in C will have ameasurable impact on the worlds energy use and co2 emissions, so the little things really matter.

C programmers claim some things that are simply not true: 1) simplicity - C is not a simple language, it is a language lacking advanced features which does not make it simple to use but it might be easier to create incomplete non-performant C compiler than compiler for better languages 2) performance - C naive/straight forward/clear implementations are not the most performant and most of the C programs are not highly optimised for performance, C compilers have had so much optimisation work done on them that they can actually generate decently performant code but if better languages received same level of effort as what C had they would be able to achieve better performance than C with smaller and safer code 3) clarity - C is not clear to read once structs and pointers are used and specially once it is optimised for performance...and then there is the preprocessor...which is a whole different language that is required to make any non-hello-world program even possible If I have to provide examples for any of the above you are either not a C programmer or you are an "advanced" C programmer that doesn't have to deal with large code bases and instead deals with small pieces and someone else takes care of the rest. I mean, just try to figure out what long int is on Linux without compiling a program and tell me that C is simple and clear language...and if you are still clinging on that lie then tell me what a struct looks like in memory so I can interface to it from another language...or even another C compiler...because C is simple and clear, right?

Not the OP, but you are conflating two very different ideas under a singular definition.

C is "simple" in the same way DNA is "simple". There is a small set of very straightforward rules, but that set provides immense flexibility. But it in no way means that any resulting object will not be complicated. Perhaps a better word than "simple" would be "non-complex", making the distinction between "complex" vs "complicated" systems.

By contrast, the features you refer to would increase the "complexness" of the language (I won't even dare use the grammatically correct word "complexity" here, lest we deviate into yet another trap of conflating definitions).

Which, I would agree with OP is, for better or worse, probably far outside C's goals as a language.

This has nothing to do with C, and everything with its intended problem domain.

You can get into pointer and memory errors in C++, Rust and Ada. All of them low-level system languages. Sure, those errors might be harder to produce, but not impossible, and definitely easy enough to still trip you up.

I programmed in all of those languages, except Rust (just don't like it). At least in C you pretty much now WHY (not necessarily where in the code) things went south, without consulting a thousand page specification or having to remember the myriad of language feature interactions that could have triggered those problems.

Moreover, C being small, it's a good on/off language. Try doing a code review for a C++/Rust/Ada code base which uses features heavily after not having touched the language for a year. I bet it is not as easy as C.

You know, some things in life are just hard. And low-level programming is one of those things. C is only honest about this.