[Prospective Vision] Improving the approachability of data-race safety

First of all, I'm happy to see the effort that is directed at this vision, with so many improvements regarding situations that I've been through in my own code and that I've seen being brought up by the community.

Regarding the “single-threaded” by default approach, I have something I'd like to shine a bit of light on:

My understanding is that the document says that one of the reasons that analyzing the program as a whole is bad is because "it would make the first adoption of concurrency extremely painful". Then, it goes on to say that a better approach is to make the single-threaded assumption in smaller parts of the program. Finally, the document proposes that these smaller parts are the modules.

Choosing the modules as the smaller parts have caught my attention because over the last 3 years I've interacted with a couple dozens of beginner Swift programmers and the vast majority of the apps I've seen them develop do not have the code they've written broken down in smaller modules. The apps are mostly composed by 1 module + dependencies.

Is breaking out of the single-threaded default on these projects with one big module possibly going to be quite painful?

If I understood it correctly, the per-module would be an improvement over the whole-program approach even on these cases because at least the package dependencies are separated.

Since specially in this vision we care so much about beginners, I believe projects structured this way should be taken into consideration. Does the LSG believe that the proposed vision brings is good enough for a good break-out experience on them?

3 Likes