> I agree C is necessary for low-level programming, but for the meat of all the other applications and usages, higher-level languages are needed.
I actually disagree with this for the most part.
C's main advantage as a systems language is its ubiquity -- virtually every platform released in at least the last 25 years has had a reliable C compiler available. Before JavaScript hit it big with Web 2.0, C was a lingua franca among programmers. Starting in the late 80s and continuing throughout much of the 90s, pretty much every textbook that had used Pascal or Pidgin Algol for code listings was edited to contain code listings in C instead.
Of course, as Java gained momentum in the education space in the late 90s and early 00s, many were again updated for code listings in Java. Although a great deal of computer science curricula now crowd around Java, most of them also have at least one required course either on C or that makes good use of C (my own track at NC State contained, beyond the introductory Java courses, "C & Software Tools", "Operating Systems", and "Computer Graphics", all in C).
That all being said, there were historically quite a few systems languages that were better than C in almost every way[1]: they were (typically both memory- and type-) safe, they were higher level in the sense that they offered more and better tools for abstraction (and were therefore considerably more expressive), they offered more opportunities for automatic optimization, they were easier to port to new platforms, many of them were easier to read and had far fewer nuances/"gotchas"/"footguns" than C, the languages themselves were designed in such a way that better tooling was possible, the list goes on and on. The one thing that C had on them was that it was already default. Programmers could (and can) count on the target platform having a C compiler. C programs have access to the wide assortment of C libraries. C was good enough. In a sense, C's popularity was and is perpetuated by the fact that it's the path of least resistance. Once C managed to get into that position, of course it became the "king of systems languages".
I think C's days are numbered. There was a time when systems programming was how you went about learning to program professionally on microcomputers. (Unstructured) BASIC was popular among hobbyists but right-out for professional programs due to abysmal performance. So, you learned assembly/machine language, or, if you were lucky, Turbo Pascal, a similar-in-spirit C system, or QuickBASIC (a compiled, structured language that I'd actually classify as a systems language, given that its feature set is mostly isomorphic to C's). Nothing else offered the level of performance you needed for commercial applications. This continued from the mid 80s through to the early 00s, yielding several generations of programmers who were systems programmers by training.
But things are different now: most programmers nowadays are cutting their teeth on high-level languages like JavaScript, Ruby, Python, Lua, etc., and if they become systems programmers it's due to their own desires and interests rather than out of any real necessity. These programmers know better, and are in an excellent position to notice the many shortcomings of C, and some even outright reject it due to its gnarliness in comparison with the high-level languages they're accustomed to. They know, deep down in their bones, that systems programming doesn't have to be so unsafe, so intricate, so field-of-landmine-ish, so... shitty. And some of them intend to do something about it.
I think we're already seeing the results of this: languages like Rust, Nim, and Myrddin strike me as products of these happenings. And now, I think, is a good time for it, because C's ubiquity has never been less relevant since its rise to power: there's only a handful of platforms anyone needs to support nowadays (POSIX and Windows, desktop and mobile; you can count OS X/iOS as a separate platform if you're feeling squirrely, but even then you haven't reached an unattainable set of targets, and it seems as if soon you may be able to strike Windows from the list as well); if you offer ABI compatibility with C, you get libraries for free; parsing is practically a solved problem; .... And then there's the LLVM, which can handle roughly a third of the compilation process for you -- and it's the backend: the hardest part!
I imagine that within another 20 years to 30 years, C will be hiding within its final strongholds of legacy code and embedded programs. Outside the embedded space, new projects in C will be exceedingly rare, and another decade or two after that will see even the embedded programmers breathing a collective sigh of relief as they become gradually liberated from the tyranny of C.
Only time will tell if the newcomers can usurp C's throne, but I have my fingers crossed. When C gasps its last breath, I will say "good riddance", and happily return to my safe, expressive, pleasant systems language, whatever that may happen to be at that time.
[1]: Just to name a few: Algol 60, Modula-2, Oberon, Ada, Modula-3(one of my personal favorites), ATS, even several non-standard dialects of Pascal such as the ones from UCSD, Apple, and Borland. Then, of course, there are the newcomers: Clay, Rust, Go, D, (does Nim count?), Myrddin (definitely one to keep an eye on), even some dialect(s) of C# were used at Microsoft Research for systems programming. I'd also be remiss not to mention PreScheme (another one of my favorites), used by Jonathan Rees and Richard Kelsey to implement the Scheme48 virtual machine, and its nephew RPython, used for implementing the PyPy JIT framework. I'm sure there are quite a few I'm leaving out, but these are the ones that come to mind at the moment (also, do keep in mind that I'm restricting this to systems languages that are strictly better than C, so some otherwise neat ones like BCPL and BLISS have been intentionally omitted).