People that make this kind of complaint were using C for the wrong type of software. If you want to write a web application in C you just need to reevaluate your tool set.
The author points out that C is gradually being superseded by languages like Python. The author is right. Every year, less new C is being written, and for good reason.
You point out that there are obviously environments (like your life support valve driver, as Julio Capote says) where C is going to be the most appropriate choice for years to come.
We can be reasonable people and accept that there's truth to both of these sentiments, or we can synthesize a phony controversy in which we compete to defend extremes and get nowhere.
If we're reasonable, I think the author's point is well taken. Less C/C++ is written every year. In part that's due to the web and the increasing power of (what we used to think of as) "embedded" environments. But in part, it's because people who would have reached for C as their go-to language for some cases are (properly) going to stop doing that.
As someone who spends most of his working days looking at other people's projects for flaws like the stuff this guy is alluding to, particularly for Python and Ruby projects --- when you want to find something particularly fun and gruesome, you go straight for the C extensions.
These devices will only continue to grow, so more C will be written not less. More Python, Ruby etc will be written too, because more software will be written in general. The proliferation of software isn't a zero sum game and probably won't be for a very long time.
My point is you can't talk about decreasing C usage without acknowledging that a huge chunk, probably a majority, of C code is for embedded applications. That segment is increasing, not decreasing. And C is used on the lion share of embedded apps, possibly upwards of 90%.
Some people out there actually know how to use C, and instead of battling with async JS do get a 5000hits/s hello world, they code a webapp that can easily handle hundreds of thousands of requests/sec without a blink.
Granted, it's less and less common.
Now, is C the best possible tool for these jobs? Certainly not. But it's the one we have and it's got a pretty fantastic track record.
The heart valve code inherits constraints that make C a lot safer: it has an extraordinarily limited feature set, its functional interfaces are simple, it changes rarely, and the time - to - market pressures it faces are dwarfed by other factors like certification and manufacturing.
Consumer software is richly functional, has complex interfaces, changes constantly, and is written under ridiculous scheduling pressure. In that environment, C does indeed give you software that is as likely to enable someone to install a trojan on your system as it is to properly render an image.