4 ms·
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 pape
by apta 12y ago
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.
- Untit1ed 12y agoI 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.
- rrradical 12y agoThey 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.
- deleted 12y ago[deleted]
- Arnor 12y agoIsn'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...
- jcrubino 12y agoScala, 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"
- nullc 12y agoAfter 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.