> programmers are strongly encouraged to use appropriate synchronization to avoid data races
Any time you need to "encourage" programmers to do the right thing, you have already failed in your language design.
And I think OP agrees with me here. OP says "static checking of correct synchronization" which is irresponsibly absent from Go.
While it does not have parallelism, the concurrency is as unrestricted as it is in go, forgetting awaits is a very common issue leading to wild tasks running unbounded and unchecked, and when you need any other synchronisation mechanism you have to write them yourself and they’re tricky indeed.
$dayjob’s JS team keeps chasing concurrency issues, and breaking builds because of them.
Single threaded languages are usually data race free. I imagine some multithreaded, purely functional languages are too (everything is immutable, and therefore cannot be modified in race with reads). Of course, SQL running in strictly serializable mode is too.
Of those, the only one of those that's an appropriate choice for systems software development is Rust. The Core C++ Guidelines are a runner up in my opinion: They dictate a subset of C++ that is safer, with the goal of backporting the Rust memory safety properties to C++. Swift has also done a lot in this space.
Go does neither. That's why there's this thread on HN that I bookmarked: https://news.ycombinator.com/item?id=31698503