[sandGorgon]

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147

[melling]

I don’t think that was the conclusion.

“ as some keen HN commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop.”

[nindalf]

I don't think it is. The top comment in that thread indicates why.

In general for most long lived workloads, I would expect Go to be approximately 15-25% slower than an equivalent C/C++/Rust program because of the CPU overhead of the Go GC. The Go team have done a lot of great work to optimize pause times and memory consumption though.

[manaskarekar]

While Go may be faster somewhere, that post was not a good comparison.

See the discussion around it and the patches made by the community and the final results.

See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-bench...

[Tuna-Fish]

And just to help the lazy people, after making the benchmarked loads equivalent, the results are:

hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out

  Time (mean ± σ):      1.888 s ±  0.013 s    [User: 2.040 s, System: 0.045 s]

  Range (min … max):    1.875 s …  1.918 s    10 runs

Benchmark #2: node javascript/main.js

  Time (mean ± σ):      4.257 s ±  0.033 s    [User: 4.295 s, System: 0.042 s]

  Range (min … max):    4.221 s …  4.338 s    10 runs

Benchmark #3: rust/target/release/rust

  Time (mean ± σ):     874.1 ms ±  50.8 ms    [User: 5.688 s, System: 0.830 s]

  Range (min … max):   813.5 ms … 1001.9 ms    10 runs

Summary

  'rust/target/release/rust' ran

    2.16 ± 0.13 times faster than 'go/out'

    4.87 ± 0.29 times faster than 'node javascript/main.js'

[burntsushi]

It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-bench...

That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.

[hu3]

The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.

[GolDDranks]

Rust is usually faster than Go. Note the edit in the previous post.

[mesaframe]

Well, I would say it's faster than Go almost every time.

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