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

To provide an alternative point of view of this - I've lost count of the number of issues and data race issues that have been caught and fixed by adopting Sendable across Vapor's codebases. Lots of GitHub issues that were impossible to reproduce, subtle data race issues, and downright stupid coding from myself. Once we adopted Sendable (and yes it wasn't an easy process, especially doing it as an early adopter) all of those issues went away. We've not had a single issue reporting a crash as a result of a data race issue.

So yes, developers cannot be trusted. We're humans, we all make mistakes, no matter how good or experienced we are. Swift's ethos is safety first and this fits well with it.

And for some iOS developers it may be hard to reason about the changes and see the benefits. But Swift is not just an iOS programming language anymore.

Side note about optionals

I remember the exact same arguments about optionals when Swift was first released. "I know what I'm doing". "The compiler is trying to baby me" etc etc. Understanding optionals is definitely far easier than concurrency, but it's the same thing of a language feature tackling common programming errors and I think we can all agree that it's been a great feature once understood. Ever tried going back to a language that doesn't have them and having to remember that null pointer exceptions are still a thing outside of Swift? :nauseated_face:

17 Likes