[hardwaregeek]

One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse.

As a result, expect some churn in your codebase. Your team will have to discover and iterate upon best practices. 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.

Basically unless you’re pretty damn sure you have product market fit (PMF) and you’re sure that rust offers an appreciable benefit to said PMF, I would not use it.

[zozbot234]

Any senior developer with C/C++ experience will probably be pretty comfortable with Rust and its ecosystem. It's not an overly complicated language.

[loeg]

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

[zozbot234]

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

[loeg]

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