Оказывается, в go, горутины как обычно реализованы наивно, через блокировки
Я с go не работал, но замечал, что внутренности php, python, go, такие как vm, gc, concurrency сделаны на уровне 5-классника
Их создатели порой вообще не знают про неблокирующие алгоритмы и продвинутые методы сборки мусора
В целом вся вот эта наша shared memory де-факто привела к тому, что алгоритмическая/многопоточная экспертиза сообщества java/jvm на порядки выше, чем у других. Для жизни сие сложновато, а для инноваций - в самый раз
С другой стороны, kotlin работает на общее снижение интеллектуального уровня коммьюнити (вы можете быть иной позиции), в конечном итоге, мы получим язык, где что такое AtomicInteger и CAS знает только Никита Коваль, о пользователи Kotlin радостно гоняют корутины
Значительная часть алгоритма посвящена разрулированию проблем вокруг работы с каналом, например, буферизация, даст ли она прирост или нет. В целом, подобный ворох проблем всегда крутится вокруг рандеву-like систем, использующие очереди
Этого алгоритма пока нет в kotlin, потому что Никита его еще не замерджил, но perf-tests, уже сделал
Специальный слайд на котором "ничего не понятно" по словам докладчика. В целом это более продвинутая версия алгоритма-рандеву с первых слайдов
Очередной доклад, размазывающий тезис "алгоритмы не нужны", впрочем таких людей и нет среди читателей данного канала