Interesting work.
It has some pretty basic flaws that are pervasive that the reader
should be aware of. First off is the "productivity" measure: the last
time I looked around, this was nearly impossible to quantify for
software development. The author chose SLOC and development time as
stand-ins for productivity. SLOC has a connection with code quality
and time of development, but development time is well known to vary[1].
In particular, development time in this thesis is linked to results in
a pretty classic "Psychologist's fallacy"[2]; the author generalizes
their experiences as conclusive. This implies in particular that
"development time" in this thesis should be thrown out for meaningful
conclusions, as the sample size is 1. It is, however, an interesting
experience report.
Another basic flaw is the connecting of 'modern' with 'good'. The
author remarks the main disadvantage of C and Fortran are their age;
this crops up here and there. Workflow tooling in Go and Rust are
major focuses by the developers: C workflow tooling is usually locally
brewed. This does not make C-the-language worse.
More on a meta level, my advisor in my Master's work drummed into me
that I should NOT insert my opinion into the thesis until the
conclusion. So I found the editorializing along the way very annoying.
And finally, and very unfortunately, the experience level of the
author appears to be low in all three languages; this is significant
when it comes to implementing high performance code.
---
Now, for the interesting / good parts of this experience report.
Standout interesting for me was the Rust speedup on the 48-core
machine. I did not expect that, nor did I expect Go to make such a
good showing here as well.
In general Go performance/memory made a surprisingly good showing
(to me) for this work. I shall have to revise my opinion of it upward
in the performance axis.
I am both surprised and vaguely annoyed by the Rust runtime eating so
much memory (Would love to hear from a Rust contributor why that is
and what's being scheduled to be done about it).
Of course the stronger type system of Rust catching an error that C
and Go didn't pick up is both (a) humorous and (b) justifies the type
community's work in these areas. I look forward to Rust 1.0!
One note by the author that is worth calling out stronger is the
deployment story: Go has a great one with static linking, whereas C
gets sketchy and Rust is... ??. I believe Rust has a static linker
option, but I havn't perused the manual in that area for some
time. For serious cloud-level deployments over time, static linking is
very nice, and I'm not surprised Google went that route. It's
something that would be very nice to put as a Rust emission option
"--crate-type staticbin".
Anyway. I look forward to larger sample sizes and, one day, a better productiv
[1] http://www.amazon.com/Making-Software-Really-Works-Believe/d...
The situation is actually far worse than just varying developer time.
[2] https://en.wikipedia.org/wiki/Psychologist%27s_fallacy