> Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inlined autovectorized code.

Everyone can agree with this. The question is whether this ought to be a property of the target platform or whether this ought to be a property of the software itself. Rust implicitly takes the stance that it is a property of the software.

Suppose we had a chip today that runs poorly due to icache thrash, so you rewrite portions of it with dynamic dispatch. Then someday we get a chip with an insanely large icache that would benefit from static dispatch. You rerewrite it. Or today if you work on embedded linux and want to use a rust library whose primary users are on powerful servers.

I will concede that I have no idea whether it’s possible to come up with a reasonable abstraction for this, because you certainly know more than me.

There are already plenty of architectural differences that change optimal trade-offs in the code, e.g. memory speed affects lookup tables vs recomputation choice and inlined data vs pointer chasing, branch prediction cost affects conditionals vs branchless/redundant code, data layout needs to be adjusted for SIMD and cache line sizes, memory hierarchy and core topology limit when it's beneficial to parallelize algorithms, and so on. These trade-offs don't even require oddball futuristic CPUs, and already vary significantly even within existing CPU families.

There are some languages that focus on "what" and magically optimize "how" (ISPC, Halide, and good'ol SQL), but for better or worse, Rust has chosen the "portable assembly" angle and micromanagement of everything. The upside is that you have very few surprises and "performance cliffs", and rest assured that if something is slow, you have enough control to fix it (as opposed to e.g. JIT-based language).

I am perfectly fine not having such difference in C++.

I'm not, because of the object slicing problem. Value types and inheritance don't mix well, and the way Rust expresses inheritance with explicit "dyn" traits solves the problem neatly.

That is a point of view, I dislike having to type dyn all over the place, and Impl Something as well, while we are on it.