Well, in theory what you say seems to make sense. In reality things do not look like this. And it isn't like I can articulate perfectly why it is so. As for

Well, in theory what you say seems to make sense. In reality things do not look like this. And it isn't like I can articulate perfectly why it is so. As for programming tiny devices, no, C++ (or even C) doesn't seem to be the right language to do that because people who should know better routinely do very stupid things in those languages for embedded applications. And it isn't just because they are some cash-strapped amateur: car-manufacturers and name-brand manufacturers of appliances have been shown to not know how to do this. Which tells me that they need languages that can help them do the right thing. Or rather: force them to address typical classes of problems or help them address these. I even saw a discussion about heap-fragmentation on an embedded system where you shouldn't be allocating memory at all -- which is not only doing the wrong thing, but doing the wrong thing badly. Sure, people should know better, but they don't. I've spent much of the past two years with my nose in embedded code and if you think the average fullstack programmer produces terrible code, much embedded code is often the stuff of nightmares. If we are to limit the discussion to larger systems, the number of things where you'd need to use C++ for performance or efficiency has shrunk down a lot. In my experience, the vast majority of performance issues come from bad design, lack of measurement, sloppiness and ignorance about algorithmic complexity rather than the ability to squeeze performance out of hardware. Sure, you can, and should, write extremely performance sensitive libraries that cling to the metal where appropriate, but this still leaves a lot you really should do in languages that provide higher productivity, security and clarity.