I think there's a third issue you didn't mention: Ecosystem/framework complexity. Writing a device driver in C is complex, sure, but pretty much all that compl

I think there's a third issue you didn't mention: Ecosystem/framework complexity. Writing a device driver in C is complex, sure, but pretty much all that complexity comes from the problem domain. C++ adds a little more incidental complexity, but if you use it to write a device driver, you're still mostly fighting "how my computer talks to hardware" - and at least that's the correct fight to be having. But if you're writing a CRUD app for the web, the incidental complexity is off the charts. Five different languages (HTML/JS/CSS/{Ruby|Python|Whatever}/SQL), three or more frameworks (Bootstrap/React/Redux/Django/SQLAlchemy)...and you haven't even deployed yet. There should be a middle position between "impoverished pseudo programming language" and "here's your five-layer web stack, have fun". If your app is basically three "if" statements and a "for" loop with some UI on top, I agree that you should write those statements in a real programming language. But you shouldn't need three layers of framework on top, just to put them in front of a user! I think this is what everyone is talking about when they bring up VB and Delphi in this thread. I don't think that "Delphi for the web" is an impossible goal - and I've put my money where my mouth is, by building a sane development platform for the web - https://anvil.works https://anvil.works. You do everything in one language (Python), with proper tooling support (hello, autocomplete!), and skip the BS. (On the other hand, perhaps this is what you meant by "CRUD apps will mostly be automated away". If so, it's only in the sense that my time is being "automated away" when I use a GCed language rather than malloc.)