It was interesting to observe that Go/Golang, while supposedly designed for concurrency, ranks the "worst" in terms of concurrency bugs (see Table 8 in the paper). I presume this is due to the absence of any way to specify immutability in the language. Of course, it could mean that because it has concurrency primitives built-in, that people are willing to use concurrency more. It would be interesting to see how a stronger type system would have an affect on such error rates.
I don't get this statement though: The enrichment of race condition errors in Go is likely because the Go is distributed with a race-detection tool that may advantage Go developers in detecting races. I thought that including a race detector would reduce race condition errors. Am I missing something?
It was also interesting to see it rank low in the security correlation ranking too.
They aren't actually analyzing whether the software has race condition errors; they are analyzing whether there are commits to fix race condition errors. If more errors can be detected, more will show up in commit logs and so the language will be deemed error-prone.
Scala, Go and Erlang are all shown to be comparatively high in concurrency errors... so this may only show languages with a concurrency focus find the concurrency errors early and often.
And the authors at least noted that "The enrichment of race
condition errors in Go is likely because the Go is distributed with a
race-detection tool that may advantage Go developers in detecting
races"
Isn't Go also more likely to be used for concurrent tasks and therefore more likely to exhibit concurrency bugs? I admit I skimmed the article and may have missed this being dealt with in the methodology...
I imagine he's saying that they're more likely to be detected and raised as concurrency bugs because of the tool, as opposed to remaining mystery "I swear it works on my local box" bugs like so many race conditions do.
After seeing many nullity handing and race bugs in Java and PHP code that I wouldn't expect to see in C project; I've wondered if safety tools don't achieve their full promise because they make it easier to be sloppy in general.
E.g. is some of their gains loss because the developer is asleep at the wheel. Some things like this are established in other domains, on cars and bikes there is some evidence that improved safety equipment increases risky behaviour.
I don't get this statement though: The enrichment of race condition errors in Go is likely because the Go is distributed with a race-detection tool that may advantage Go developers in detecting races. I thought that including a race detector would reduce race condition errors. Am I missing something?
It was also interesting to see it rank low in the security correlation ranking too.