[empath75]

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.

[jdub]

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]

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

[aliceryhl]

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]

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

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]

Yeah it’s definitely around using clones everywhere.

[masklinn]

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