[J0-nas]

I'd agree but

> Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.

I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1].

But then again, I don't know what kind of computing requirements they have. Is there a reason why GRP computing isn't mentioned? They are really efficient and CUDA isn't that hard to learn.

> Rust allows the user to avoid common mistakes such as the access to invalid memory regions and race conditions

They seem to care about safety.

[1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

[claudius]

> I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1].

Certainly, this was really only taken as a ballpark estimate of the performance difference. Looking at your link, it seems to have been slightly overestimating the difference, though the general point still stands: C is (in most cases) faster and there is (nearly) no case in which Go beats C.

> Is there a reason why GRP computing isn't mentioned?

> They are really efficient and CUDA isn't that hard to learn.

Sorry, not sure if you mean GPU instead of GRP in the first sentence. CUDA helps to some degree, but not always, e.g. when you are memory bandwidth bound (common in tensor networks in physics). I have no experience with Monte Carlo methods and can’t comment on whether they substantially benefit from CUDA; I know of at least one (Quantum Monte Carlo) code which runs much faster on a standard Xeon than on the Xeon Phi, though.

> They seem to care about safety.

Yes of course safety is nice to have and I’ll gladly learn Rust when I have some free time to get that safety at hopefully zero cost. But sacrificing performance is simply not competitive, if you can throw someone with gdb at the problem and get essentially the same "safety".

[bluejekyll]

> if you can throw someone with gdb at the problem and get essentially the same "safety".

That's an odd tradeoff. That time of debugging could be significantly longer than just writing the software in a safe language. Seems like a bad tradeoff, and in many scenarios, bugs can lead to very bad things that you can't recover from. I've experienced all of these, having to fix them over long periods of time (not all my code, but sadly some was): data loss, concurrency (tough to debug in gdb), major memory leaks (even from std libs), corrupted data because of misused non null terminated c strings, array out of bound issues. Each one of these took weeks to track down, maybe because I'm not smart, which is a valid criticism; with Rust I've never had issues with any of those (2 years and running), and given that I'm not smart, it helps me by telling me where I got something wrong.

Be safe out there people...