Rust initially didn't require `dyn` prefix for dynamic dispatch (trait object types), but the lack of syntactic distinction was confusing to users. Rust is low-level enough that there is a semantic difference which one you use (Rust calls it "object safety"), so you can't just pretend there's none.

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.

> 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.

Can these code changes be automated with a tool?

One of the strengths of Go and Java is the ease of writing tools. C++ on the other hand is a mess since it's hard to look through templates (concepts probably help) and macros (good luck).

Do just like in Go and Java, use an IDE.

Not sure I agree with this. The relative similarity between static and dynamic dispatch in C++ is pretty confusing (to me) (edit: as in, 'virtual' vs non-'virtual' methods).

?? They appear completely different in C++, i.e. virtual functions vs. templates

https://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic...

I also wish they were more similar in both C++ and Rust. I find that most programs get more dynamic as they get bigger, get more usage, and get more extensible ... but the tendency is to want them to be as efficient as possible at the beginning.

> They appear completely different in C++, i.e. virtual functions vs. templates

Virtual vs non-virtual functions.

OK there is some static dispatch in regular functions with respect to argument overloading, e.g. f(int) and f(char), or obj.f(int) and obj.f(char).

But I think what is more commonly thought of as "static dispatch" is various template programming patterns, as in the blog post, which are more flexible, and has equivalents in Rust AFAIK.

Overall it does feel like there are too many similar mechanisms that look extremely different!

Would a regular non-virtual non-template method be considered single dispatch? I am pretty sure this is correct but I've never actually thought about this until I read your comment!

Oh, let’s not set the bar so low by comparing to C++. ;)

Two ends of the spectrum and I think the ideal is somewhere in the middle.

Instead of enums, how about something similar to Scala's sealed trait syntax to tell the compiler that I'm actually doing a static dispatch?

Enums and "sealed" classes enable closed vs. open dispatching. Static (compile-time) vs. dynamic would effectively be devirtualization.