Sure, there are many situations where sacrificing performance in exchange for a VM is totally appropriate. If you think this covers 99% percent of applications (or even 50%!) then you may only be thinking of a very small subset of software development.
Also, inefficient code produces excess heat. Meaning reduced battery life and noisy fans. So all software that gets used a lot should be optimized for performance just to conserve energy.
This statement was true in the '90s. Nowadays, the amount of high-level software written as a ratio of total programmer-hours is probably upwards of 90%.
Out of the hundreds of thousands of programmers out there, very few of them write kernels or drivers. Even fewer write window managers—there are maybe a dozen of them in active use, and most of them have either zero or one maintainers. Four software companies, out of thousands and thousands, write Web browser engines; two of them share most of their engines' code. With few exceptions, all of the codebases I mentioned date back to the '80s or '90s, when most of the code was written.
People seem to think that the software stack on a typical desktop OS is constantly under heavy development. It's not. Most of it is in maintenance mode or effectively unmaintained.
Don't take my word for it—look at the "who is hiring" threads on HN lately. There's some C++ in there, sure, but nowhere near the figure you quoted.
C++ still tends to be king when it comes to games, especially when you start talking about the console market. [1][2][3]
Finally, punch C++ into whoishiring.io. Be amazed at the market.
[0] https://www.tiobe.com/tiobe-index/
[1] https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/devel...
[2] https://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY
[3] http://news.softpedia.com/news/unreal-engine-4-15-brings-nin...
Not to mention private companies developing software to analyze heaps of data from finance to web searches.
What makes this an appropriate metric? What about, for example, the ratio of total user interaction time?
The lower layers of the stack may not need as much programming attention compared to the top of the stack, but that's only because the stack is top-heavy in terms of programs produced.
But in a given stack, the set of applications at the top of the stack is still not particularly big (most users do not use most applications). On the other hand, everything that users do passes through the lower parts of the stack (most users use the kernel, drivers and the graphics layer constantly, even if indirectly).
The story on power consumption of managed/VM language is still not clear. Most of the computation in the world are now happening in mobile/IoT devices and cloud/data centers; Both environment put a strong constraint on power consumption and therefore on efficiency. There is already a huge amount (and growing ) of native code running in the cloud. As our computational requirement increase (and unless we have a break through in computation efficiency) people might want to revisit the lost implied by managed environment.
The other side of the coin is that managed env. are popular because they usually bring safety, ease of programming and productivity. Modern C++,rust and D are showing that a lot of those attributes can be had with native languages too.
But for hobbyist work, it is different. Free software developers are seeking universality more than anything else. They want as many people as possible to be able to use their code, be able to read it and contribute to it.
VM:s hinder universality. For example, if you write an image processing library in C then everyone can theoretically use it (assuming bindings are non-trivial to write). But if the same library is written in a VM language, then it is only usable to developers who are using that platform.
It's like a curse.
