Evaluation of C, Go, and Rust in the HPC environment [pdf]

GitHub repo with all of the code: https://github.com/mrfloya/thesis-ba

Most interesting part of the thesis, for me, is page 42:

> In this case it was even an advantage that the Rust version was developed last since it revealed a critical error in the other implementations.

Null strikes again!

Yeah it would of been nice to see the dev time split up into setup and actual programming.

I'm a bit surprised that the author didn't mention julialang.org in the report - it's much more suited for technical / scientific computation, while Go and Rust seem better for systems-level concurrency/design.

I feel that it's a shame to test C rather than C++, because the latter offers so many advantages to developer productivity -- the paper cites memory management and type-related errors as being major causes of developer unproductivity, and C++ has automatic memory management and templates and such.

Also, it doesn't restrict the use of C libraries, so even if you've been writing C for HPC code all these years, there should be minimal technical difficulties in switching over, except for the time it takes to learn C++, which shouldn't be long if you know C well.

The author has a "lack of equal experience in the three evaluated languages", especially C, but is comparing them for development time and SLOC based on a sample size of one developer and one very small program.

He rewrites a distributed program as a threaded one, because Rust and Go didn't have a distributed computing library, but says Go and Rust have "similar performance" in HPC.

He says he was surprised at the C performance, but there's no investigation of a cause. Maybe just because C is slow...

I don't mean to be overly critical, but these results in the paper mean absolutely nothing. It's a waste of time.