4 ms·

As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extre

As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extremely slow code in rust than it is in go, but once you start optimizing, rust will generally be faster, sometimes by quite a lot. I’ve also run into fewer pathological cases as I’ve learned more of the idiomatic rust patterns.

rat9988 6y ago
>it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.
- baq 6y ago
  likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.
  - empath75 6y ago
    Yeah it’s definitely around using clones everywhere.
    - masklinn 6y ago
      I don't know that clones are problems in and of themselves rather than what they do behind the scenes: allocations. Cloning an Rc is completely innocent, cloning a HashMap<String, Vec<String>> is deadly in a way you may not expect if you're used to shallow-copying hashmaps (or even deep-copying them). And it's true that if you think of allocations as being no big deal unless you're aiming for very high performance, your Rust is going to be slow (also your C++ and your C).
jdub 6y ago
And yet, a lot of experienced programmers have noted that even when they write their first time naïve Rust, it turns out to be really fast.
- sanxiyn 6y ago
  For example, Bryan Cantrill wrote about his experience in "The relative performance of C and Rust". I found the post fascinating. http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
aliceryhl 6y ago
I have the opposite feeling. Every time I do something that could be expensive or incorrect, the language makes sure that I notice, which I find extremely helpful in writing fast code the first time around.

rat9988 6y ago

>it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.

baq 6y ago
likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.
- empath75 6y ago
  Yeah it’s definitely around using clones everywhere.
  - masklinn 6y ago
    I don't know that clones are problems in and of themselves rather than what they do behind the scenes: allocations. Cloning an Rc is completely innocent, cloning a HashMap<String, Vec<String>> is deadly in a way you may not expect if you're used to shallow-copying hashmaps (or even deep-copying them). And it's true that if you think of allocations as being no big deal unless you're aiming for very high performance, your Rust is going to be slow (also your C++ and your C).

jdub 6y ago

And yet, a lot of experienced programmers have noted that even when they write their first time naïve Rust, it turns out to be really fast.

sanxiyn 6y ago
For example, Bryan Cantrill wrote about his experience in "The relative performance of C and Rust". I found the post fascinating. http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

aliceryhl 6y ago

I have the opposite feeling. Every time I do something that could be expensive or incorrect, the language makes sure that I notice, which I find extremely helpful in writing fast code the first time around.