Альтернатива синхронным мьютексам - асинхронные мьютексы.
Они предоставляют то же АПИ, но не локают системный тред.

Синхронные мьютексы в асинхронном коде можно использовать, если MutexGuard не будет храниться между авейтами (потому что теперь мы знаем, что критические секции очень маленькие и быстрые, и поэтому немного подождать не страшно)

синхронные лучше вообще не юзать, во избежание. Благо асинхронные имеют то же апи за исключением "await"

Ну да, синхронные мьютексы это уже оптимизация.

как бы я не говорил что в расте это не работает. Сомневаюсь конечно, но допускаю. В любом случае что по факту получается - куча обвески для асинхронщины, тонны граблей (понять что именно сделать асинхронным, а что нет), очень тугой апи для примитивов синхронизации. Плюс ещё обвеска на borrowing чтобы конпилятор ощасливить (это то с чем я сталкивался). Плюс всё это опенсорцное и доверие к этому не 100%. Ну и зачем?)

сказано много) А по факту только претензия борровчекера имеет смысл

остальное так же как и везде

граблей я на го больше собрал, когда задедлочил всек херам потому что сделал форыч по каналу, а надо было фор по числу детей

а всишарпе/джаве есть асинхронные мьютексы?

Очень удобно когда poll() напрямую реализуется.

как раз потому что по привычке из раста думал что канал сам закроется когда последний ребенок в него напишет и дроп остановит форыч

есть

Ну да, но это тоже нечастый кейс.

ну а как же тот факт, что в го это в язык встроенное, очевидное и не требует обвески?

А контексты надо все равно руками пробрасывать

по-моему это минорно. Из разряда является ли for кейвордом или есть это функция как в руби

ErrGroup, Context - это не обвес?

да как-то насрать) Минимальные различия

ну ок, допустим мьютексы асинхронные. А как на счёт cpu bound вычислений?

Создавать каналы и блокироваться на них для await'а - это не обвес?