> a subtle data race and a rare deadlock
That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).
That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).
Most that can recall achieve this by simply not having any locks at all. That's feasible with some careful design.
Outside proof-oriented languages though, I'm not aware of any that prevent livelocks, much less both. When excluding stuff that's single threaded but might otherwise qualify, e.g. Elm. "Lack of progress" is what most care about though, and yeah that realm is much more "you give up too much to get that guarantee" in nearly all cases (e.g. no turing completeness).
Meanwhile I copy-pasted a Python async TaskGroup example from the docs and still found that, despite using a TaskGroup which is specifically designed to await every task and only return once all are done, it returned the instant theloop was completed and tasks were created and then the program exited without having done any of the work.
Concurrency woo~
On concurrency, Go has the bolts screwed in; it basically was 'lets reuse everything we can from Plan9 into a multiplatform language'.