Just a wake-up call. Every x years there's a new language that will replace C.
Yes yes, I started right away saying this. Nobody needs to be waken up in this thread, I'm pretty sure.
The main reason why C still sticks, apart from its own merits (and it has a lot of them obviously despite some of its shortcomings), is just that it's become industry-standard and is standardized. With actually a decent standard. Yeah, I know some may whine about it, but just take a look at the C++ standard, and come back. I think you'll see how good the C standard is after that quick adventure.
The whole point of this thread was collectively figuring out what features could make C better without compromising any of its fundamental benefits. For this, I think we have gotten a few points that I'll summarize here (likely not exhaustive at all):
- Better, more consistent arithmetics;
- Partly related: no risky implicit conversions;
- Much fewer, or ideally no undefined behaviors;
- Modules;
- Constrained types (such as ranges) - could also be used for bound checking when indexing arrays/buffers;
- Tagged blocks, for easier and more consistent flow control;
- Getting rid of the C switch with fall-through;
Points about parallelism have been made, but as some have said, I'm not too sure having built-in support in the language would dramatically change things, part from sugar coating. It may make the developers' life a bit easier, but for a dramatic change, different computer architectures more adapted to parallelism should probably be devised first. Another thing to consider with this is that built-in support for parallelism almost inevitably implies offloading the nasty work to some runtime. It's kinda displacing the problem without fundamentally solving it.
Of course another point was, as a corollary, to figure out what exactly would prevent any new language from taking off. The mere fact that those "are not C" partly explains this - see above - but there are oither reasons. As discussed earlier, one big problem is that most of those attempts have been lacking pragmatism, have essentially been one-person projects (so, way too opiniated approaches, lacking proper reviews of real-world practices), and have been much, much too complex. Yeah. If you wanna avoid the pitfalls of C++, do not fall into the same trap! Too complex languages with a bunch of programming paradigms stacked together are confusing, almost impossible to master, promote language fragmentation (which hinders maintenance), tend to make developers misuse them, make developing compilers a hell, the list is long...
Yeah, Rust is nice, but IMHO it has fallen into this exact trap heads down.
As to C++, I've found this "FQA" rather to the point:
http://yosefk.com/c++fqa/index.html , and this can also trigger some thinking if you're ever considering designing a new language.