5 ms·

While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thin

While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thinking about it (as they are called automatically).

ocschwar 6y ago
Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.
- xena 6y ago
  Doesn't the compiler optimize out clones when it can?
  - sanxiyn 6y ago
    No, not really.
  - tylerhou 6y ago
    Probably not; detecting unnecessary clones is expensive for non-trivial cases. If a human can't prove that the clone isn't necessary (by writing the code in such a manner that the borrow checker accepts), I doubt the compiler could.
  - toby 6y ago
    There's a Cargo tool called "clippy" which will tell you if it finds unnecessary clones.
- rogers18445 6y ago
  The vast majority of the code you write is glue code, you can be as inefficient when writing it as you want and it doesn't matter. Optimize only what the profiler tells you your cpu is spending real time in.
- brundolf 6y ago
  This is one of the psychological traps I've experienced writing Rust: in Python or Java you can't hope to make things more efficient at a certain point. You couldn't get clever with string re-use if you tried, etc. So you're content to just move forward and be practical. Whereas in Rust you know that it's probably possible to use a &str there instead of a String. If you just bang on it a little longer, you can make it just a bit more optimal. The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. You usually don't have to optimize them out! Your code will probably be faster than Java even with a bunch of clones, etc! But there's this temptation that's really hard for programmers to resist, to sink hours and hours into making things just slightly more optimal given the opportunity. You have to consciously talk yourself out of that if you want to be productive.
  - masklinn 6y ago
    > The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. That's… not exactly true. `Vec::new` is completely free so that's a different debate, but much as in C++ or C allocations in Rust are much more expensive than in managed languages: 1. system allocators genuinely suck, all of them, though some more than others (iirc macos' is especially bad) 2. managed languages can much more easily specialised allocation strategies (freelists, bump allocators, type-custom allocation strategies), this is either difficult / impossible (no custom allocators) or way more painful (manually pass custom allocators in) in Rust As a result, allocations in Rust are really tremendously slow by default, it's not too rare to see questions about Rust programs which are slower than managed equivalents, in release mode. Because the rust program is allocation heavy (relatively), it might have 10% the allocations of the non-rust program but the allocations are 100 times more expensive.
    - brundolf 6y ago
      Interesting, I hadn't heard this before. Do you have any resources I could read? Edit: I do know that languages where strings are immutable use that fact to do lots of optimization (automatically sharing "copied" strings and just cloning reference-counters, for example), but you can accomplish some of this in Rust too with Rc<> or even persistent data structures if you really want to. And of course there are cases where it's more efficient to actually mutate a string, which these languages can't do. But it sounds like you're talking about something else?
wyldfire 6y ago
I clone all the time to make the borrow checker leave me alone. If this code shows up as a hot spot in a profile I can spend the extra energy to optimize it. I hope to evolve my understanding so that I can do the right thing at design time to minimize unnecessary clone()s.
dman 6y ago
People do think about this all the time in C++ and it is very common to get code review comments about avoiding copies if you overlook such things.
- Koshkin 6y ago
  Yup, and I wish the compiler would give a warning on a use of a copy constructor...
nemetroid 6y ago
I've never seen C++ that isn't cautious about copying as little as possible.
- masklinn 6y ago
  A big difference is that C++ copies implicitly. Rust has the opposite default, it will never clone implicitly.

ocschwar 6y ago

Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.

xena 6y ago
Doesn't the compiler optimize out clones when it can?
- sanxiyn 6y ago
  No, not really.
- tylerhou 6y ago
  Probably not; detecting unnecessary clones is expensive for non-trivial cases. If a human can't prove that the clone isn't necessary (by writing the code in such a manner that the borrow checker accepts), I doubt the compiler could.
- toby 6y ago
  There's a Cargo tool called "clippy" which will tell you if it finds unnecessary clones.
rogers18445 6y ago
The vast majority of the code you write is glue code, you can be as inefficient when writing it as you want and it doesn't matter. Optimize only what the profiler tells you your cpu is spending real time in.
brundolf 6y ago
This is one of the psychological traps I've experienced writing Rust: in Python or Java you can't hope to make things more efficient at a certain point. You couldn't get clever with string re-use if you tried, etc. So you're content to just move forward and be practical. Whereas in Rust you know that it's probably possible to use a &str there instead of a String. If you just bang on it a little longer, you can make it just a bit more optimal. The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. You usually don't have to optimize them out! Your code will probably be faster than Java even with a bunch of clones, etc! But there's this temptation that's really hard for programmers to resist, to sink hours and hours into making things just slightly more optimal given the opportunity. You have to consciously talk yourself out of that if you want to be productive.
- masklinn 6y ago
  > The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. That's… not exactly true. `Vec::new` is completely free so that's a different debate, but much as in C++ or C allocations in Rust are much more expensive than in managed languages: 1. system allocators genuinely suck, all of them, though some more than others (iirc macos' is especially bad) 2. managed languages can much more easily specialised allocation strategies (freelists, bump allocators, type-custom allocation strategies), this is either difficult / impossible (no custom allocators) or way more painful (manually pass custom allocators in) in Rust As a result, allocations in Rust are really tremendously slow by default, it's not too rare to see questions about Rust programs which are slower than managed equivalents, in release mode. Because the rust program is allocation heavy (relatively), it might have 10% the allocations of the non-rust program but the allocations are 100 times more expensive.
  - brundolf 6y ago
    Interesting, I hadn't heard this before. Do you have any resources I could read? Edit: I do know that languages where strings are immutable use that fact to do lots of optimization (automatically sharing "copied" strings and just cloning reference-counters, for example), but you can accomplish some of this in Rust too with Rc<> or even persistent data structures if you really want to. And of course there are cases where it's more efficient to actually mutate a string, which these languages can't do. But it sounds like you're talking about something else?

wyldfire 6y ago

I clone all the time to make the borrow checker leave me alone. If this code shows up as a hot spot in a profile I can spend the extra energy to optimize it. I hope to evolve my understanding so that I can do the right thing at design time to minimize unnecessary clone()s.

dman 6y ago

People do think about this all the time in C++ and it is very common to get code review comments about avoiding copies if you overlook such things.

Koshkin 6y ago
Yup, and I wish the compiler would give a warning on a use of a copy constructor...

nemetroid 6y ago

I've never seen C++ that isn't cautious about copying as little as possible.

masklinn 6y ago
A big difference is that C++ copies implicitly. Rust has the opposite default, it will never clone implicitly.