>Rather than mentally implementing something in C/C++, and then thinking, “how do I translate this to Rust in a way that satisfies the borrow-checker?”, it’s be

>Rather than mentally implementing something in C/C++, and then thinking, “how do I translate this to Rust in a way that satisfies the borrow-checker?”, it’s better to think, “how can I accomplish the goal within the semantics of Rust, thinking in terms of linearity and lifetimes?”. I still do think about it all in C++ terms. Borrowing and ownership are just specific terminology for things that you must know to create a correct C++ program of any useful complexity and performance. Two common anti-Rust arguments are: - It's hard to learn - You should just git gud at C++ But the Euler diagram of people who struggle with the borrow checker and people who are gud enough at C++ has no overlap. Likewise String and &str. I also think it means the performance user story is, somehow, underappreciated, especially for naive users. Immutable borrows and moves are just part of the development experience, and copying is the unobvious path. And if you still struggle you can often just toss in `rayon` in ways that you never could with `std::execution::par`