Your Rust program corresponds to my second Rust program.

Your Go program is not what I would expect. A bufio.Scanner is the idiomatic (and naive) way to read lines in Go. But this is immaterial. Your results are consistent with mine. They aren't different. I just included more analysis and more programs to provide proper context to this challenge of yours.

I gave you naive solution, now lets see amateurish solution (someone totally new to both languages)

Rust 4.6s

Go 3.1s

http://pastebin.com/r6K22Dt2

EDIT:

Using grep 0.6s

Then I have installed rigrep and...

Using ripgrep 0.4s

Really nice burntsushi. I am surprised by those (ripgrep) results compared to grep.

Seems I can't reply to your other comment, so I'll reply here. How can you say that my naive implementation is not naive? What is not naive about it? It's very naive. It's basically the same naive code that you were writing, but in actual idiomatic Rust with the linting issues fixed.

Using a `lines()` approach is naive because that allocates owned heap-allocated strings. An optimal, non-naive solution would not use heap allocation for buffering lines but use a stack-allocated array. That alone would bring significant speedup versus the line approach.

As for ripgrep, it's a pretty comprehensive application that makes use of SIMD/AVX so it's only natural that it's fast.

Your solution is not naive in my opinion because you set the size of the buffer and use map/filter but ok... Let's check. Your solution is the slowest from all the solutions.

It took 4.6s which only confirms what I wrote on beginning when we started this discussion. Perf counters for your solution in here:

http://pastebin.com/Anak1ahe

Your Rust example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust.

https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91...

As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabling LTO, setting O3, disabling jemalloc, and using the musl target. All these things can make significant differences to the performance of the binary that's produced.

I don't know if you noticed but we are discussing naive solutions which I've mentioned couple of times in previous posts. Code you linked is not naive solution. Things you proposed to do are not naive either.

Here's the thing; it is a naive solution. You may not want to accept it because that contradicts your claim of the Go solution being faster, but at that point it becomes a he-said/she-said kind of scenario because I can claim that your Go solution isn't naive as well and have exactly the same "validity" for such a claim as you do.

Anyway this really doesn't matter as his solution is the slowest of all which confirms what I wrote and contradicts what he wrote.

For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution? I know I can't. For everyone naive solution is something different, what I saw in burntsushi reply and what I wrote myself is the closest to what I think are naive solutions.

> like enabling LTO, setting O3, disabling jemalloc, and using the musl target.

And this is for sure not part of naive solution either.

> You may not want to accept it because that contradicts your claim of the Go solution being faster

This is not true. You can find perf numbers of his solution in my second reply to him. Or you can compare those solutions yourself.

> For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution?

You can't prove a negative.