I was very familiar with C before starting to do professional work in Rust, and ran into a similar trap as the grandparent comment describes. Since then I've gained professional experience in C++ as well. Without specific Rust experience, I wholly disagree that "any senior developer with C/C++ experience" will have a good sense of optimal Rust project architecture out of the gate. A reasonably good starting point, sure. But it's a different enough language that you can't just reduce architecture concerns to "it's not overly complicated."
> ran into a similar trap as the grandparent comment describes.
The only "trap" I've seen referenced wrt. Rust is the concern that coding for agility and flexibility introduces boilerplate. Such as GP's concern about calling .clone() too much instead of worrying about lifetimes. But every language has its unidiomatic parts; it's a benefit of Rust that they chose to make the most thoroughly refactored style look "clean and natural", and the most open to refactoring "hackish and unidiomatic" rather than the reverse (cough, cough Java cough, cough). Describing that as a pitfall is just not very helpful!
Wasting time on things that don't matter is a trap. It's (IMO) easy to run into this when you're new with Rust and aren't sure of best practice patterns/conventions.
> Avoid the impulse to spend too much time code golf refactoring because “oh I can use a proc macro to decrease boilerplate while avoiding the orphan rule and having nice traits!” Rust can definitely nerd snipe you by making you worry about some very small edge case like oh no I’m copying a few too many times.
You can definitely spend too much time refactoring in other languages, but I found I was more tempted to do so in Rust than in C (perhaps due to familiarity with C).
