We can't push Java or Python to be maximally efficient (not wasting a single cycle or byte over the absolute optimum), so we don't use them for use cases where that would matter. Therefore, we don't try to push Java or Python optimisation as far as possible. Being faster is always nicer, but it can never be essential to be optimal, because you wouldn't be using those languages if it was.
Whereas we can push C++ that far, so we do use it for use cases where absolute optimality matters. Hence the community around it values the ability to do that, and we end up with all sorts of weird and awkward stuff.
C++ also has a lot of weird and awkward stuff that is nothing to do with this, i should add. Most of that is ultimately due its age and C heritage, i think.
Firstly, let's dismiss this idea that C++ can avoid wasting a single cycle or byte, it doesn't aim for that. It aims for a much lower bar, albeit still a significant achievement - it says you won't do better by hand. It will very occasionally not meet this lower bar because some people like perverse challenges. That ludicrously fast Fizz Buzz implementation (so fast that inter-core CPU bandwidth alters how fast it seems) in raw machine code can't be duplicated in C++ for example. But on real problems with real programmers you won't do better by hand and should stop trying.
OK, so there are limits. Further though the fact that you sometimes want to be able to do something did not require that C++ insist upon you doing that all the time.
There are places where they didn't. HN recently discussed structure layout and padding. You can write a C++ program with explicit structure layout and padding (I think this may not be portable though) which can significantly alter performance - but you don''t have to. If you're OK not worrying about it, C++ won't optimise layout for you (as Rust would) but it also won't ask you questions about alignment and layout, they're just left alone.
But for some things they insist. Manual memory management for example. The language doesn't (in practice) provide garbage collection, so you are responsible for picking up the trash even if you don't care about that problem. Arithmetic is another, even if it's not performance critical for you, C++ insists you need to cope with the vagaries of machine arithmetic anyway and care about things like overflow and Not-a-Number.
And this burden imposes a real cost on programmers which, at the end of the day, means they actually produce slower/ bigger code than they might have.
> Firstly, let's dismiss this idea that C++ can avoid wasting a single cycle or byte, it doesn't aim for that. It aims for a much lower bar, albeit still a significant achievement - it says you won't do better by hand.
You're referring to the "zero-overhead" goal of new C++ features. I think the above poster was talking more generally about one's ability when using a language to implement some critical subset as fast as possible or with as little memory use as possible. I suppose it's arguable if you're still doing C++ when you use intrinsics. Though I think pragmas are certainly fair game. At least C++ (and C considered as a subset) is the biggest high-level language with such a possibility.
Zero overhead abstraction is often discussed, but the explicit design goal of C++ according to its author is that there shouldn't be a language between C++ and ASM. I.e. while you can do better in asm, it shouldn't be possible to do better in another higher level language C++. If you can it means that C++ is missing some feature.
We can't push Java or Python to be maximally efficient (not wasting a single cycle or byte over the absolute optimum), so we don't use them for use cases where that would matter. Therefore, we don't try to push Java or Python optimisation as far as possible. Being faster is always nicer, but it can never be essential to be optimal, because you wouldn't be using those languages if it was.
Whereas we can push C++ that far, so we do use it for use cases where absolute optimality matters. Hence the community around it values the ability to do that, and we end up with all sorts of weird and awkward stuff.
C++ also has a lot of weird and awkward stuff that is nothing to do with this, i should add. Most of that is ultimately due its age and C heritage, i think.