You can compile any language down to C or C++, but that doesn't mean that it will run as fast as well-optimized C/C++.
The moment you include dynamic dispatch, auto-conversion to big integers, or one of a zillion of other high-level features without also introducing ways for the programmer to indicate how the compiler should implement them, you give up being just as fast as C/C++.
Yes, the difference may be small, and spending time on improving your compiler can make it smaller and smaller, but for any 'real world program', it won't be zero.
The same is true for C vs assembly, but there, the difference mostly _is_ small because C has none of those high-level features.
Also, few people have the skills and the time to wrote well-optimized C/C++.
bam, nailed that shit, especially the point about performance costs inherent in a feature set rather than in a language.
I just didn't want to continue a conversation with someone who thinks adjusting the age old "optimizations will eventually make it as fast" to be "compiling to C/C++ as an optimization will eventually make it as fast" was somehow going to magically make it come true.
It's the same old argument reskinned, and as you pointed out, the feature set has a lot to do with it.
I said nothing about "compiling to C/C++ as an optimization." I said targeting C++'s semantics (i.e. having only features C++ already has) makes a language fast.
The moment you include dynamic dispatch, auto-conversion to big integers, or one of a zillion of other high-level features without also introducing ways for the programmer to indicate how the compiler should implement them, you give up being just as fast as C/C++.
Yes, the difference may be small, and spending time on improving your compiler can make it smaller and smaller, but for any 'real world program', it won't be zero.
The same is true for C vs assembly, but there, the difference mostly _is_ small because C has none of those high-level features.
Also, few people have the skills and the time to wrote well-optimized C/C++.