I feel like concurrency introduces vast complexity and thus results in more errors, but I have no empirical data to support this. Does anyone have any go-to papers/data on such a thing?

Depend on the programming language used. Look at how Erlang solves the problem and handle concurrency.

This looks like a great paper – thanks. I think we generally see concurrency through the lens of languages that have been designed to largely functionally transform inputs to outputs, and to manage any change in a sequential manner. Concurrency is also inherently a more complex domain. However, the vast majority of our problems with concurrency are not its essential complexity, but that we’re not approaching it in a principled way and using tools that are appropriate to work with it. Progress has been made with tools. Some of them tacked on to our existing languages (eg, queue based programming, reactive programming, actors, software transactional memory), some theoretical. My personal view is that probably “the right way” to handle concurrency might be something like composable state charts. This feels like a sweet spot that would handle an enormous class of use cases in a really robust and clarifying way. Rather similar to the success of automata in language parsing. There’s work being done on petri nets that also looks very promising and would presumably handle a larger class of problems.

Erlang and Pony are two languages that make concurrency much more easy, with erlang you even get parallelism almost for free. It's fun to solve a problem just by modeling it as actors and having it use all your cores without any explicit work on your side

I should have mentioned Erlang under “progress has been made with tools”. Am I right that its actor model doesn’t validate a concurrent and distributed system, but it does make it a lot easier to build and removes many kinds of error?

yes, it makes it really easy, lot of things you don't have to care about, in fact, by looking at the code if you use OTP you don't see any explicit part that mentions or handles concurrency

It’s odd, but this paper suggested Erlang actually had higher rates of concurrency errors: https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/abstract

you write more concurrent code with them because it's easier (I guess)

@Daniel Hines that study didn't replicate https://arxiv.org/pdf/1901.10220.pdf

Aha, so perhaps my internal compass isn’t completely broken! It was a bit crushing to think that all my sensibilities about programming weren’t producing measurable results.

wow! partisan is really cool

Thanks @Mariano Guerra

I've never used Erlang but I've used Akka quite a bit. I find it a lot better and (mostly) less error-prone than threads and mutexes, but coherence business logic gets lost in translation. I think streams async/await do a much better job of keeping logic coherent, at the cost of some power and generality