@Odomontois Может ты в курсе, котлиновские корутины откуда-то слизали или

это инновационная разработка?

инновация.

Сергей, даже когда ровно тот же механизм в скале в 2011 году сделали, это не была инновация

А я не в курсе. О чем речь?

async/await это трансформация куска кода в вызовы стейтмашины, замораживающей продолжение в стейте, исходная форма зародилась в функциональном программировании я хз где-то в конце 70-х, называется delimited continuations

а если говорить в контексте скоупов и диспатчеров?

а ну тогда в 70х в функциональном программировании, называется delimited continuations

а это точно то? просто скоупы это больше о создании некоторых «вложенных асинхронных структур», которые удобно (ожидаемо) кенселятся/падают

конечно, про то, скоуп - это синтаксическое окружение внутри ресет

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

питоновские функции это не то же самое, что structured concurrency (не люблю этот баззворд, но я думаю выше уже пояснил что вкладываю в это понятие)

вы с async в питон знакомы?

угу, обычный итератор. async правда и о стейт машине ничего не знает, этим внешняя либа занимается (asyncio как правило)

ну вот, так каких аспектов структурной конкаренси вы здесь не находите по сравнению с решением в kotlin

не итератор, конечно

async def вообще конечно знает

ну любой генератор это итератор, поэтому я просто смотрю на как на частный случай итератора и соотв. могу неточно говорить.

не совсем так

вроде генераторы определяют метод _iter_.

ну хорошо, но "обычный итератор" в этом контексте всё же странно звучит https://t.me/scala_ru/325642 итератор, но необычный, сформированный необычным способом, способный принимать значения из внешней сопрограммы, а не только передавать

Деградация

сложно привести пример, понятный всем, поэтому приведу более специфичный кейс, который не говорит об общей мощности скоупов в котлине. допустим у меня есть телеграм-бот, я хочу, чтобы когда он упал я его перезапускал. нужно держать в голове, что внутри бота кто-то мог сделать create_task и поэтому обычный try - catch не спасёт. а спасёт что-то такое. но ведь может понадобится не только ловить самые верхние ошибки, это плоская асинхронная структура, потому что если запущенная из другой корутины корутина выкинет ошибку - она всё равно сможет быть поймана только в глобальном хендлере. в котлине не же, есть некоторая структуризация и вложенность асинхронности, таким образом просто написав val handler = CoroutineExceptionHandler { … } launch(handler) { … } мы можем поставить хендлер на все ошибки, которые выпадут из корутин, запущенных в блоке launch. т.е. структурно корутины в питоне выглядят так. т.е. все запущенные корутины [условно] не складываются в какое-то одно место, а каждая корутина знает кто её родитель (из какой корутины она была запущена), кто её дети (запущенные из неё корутины) и все умеют друг друга отменять в случае чего, не мешая другим. корутины в котлине - дерево, а не плоская структура.

это на самом деле относится именно к библиотеке kotlinx coroutines, которая выполняет корутины, а не к самим корутинам, но всё же.

так в питоне ты пишешь просто try и евейты прокидывают ошибки, и так же примерно везде, т.е. в котлине бойлерплейт уровня .handleError ,и в питоне ты можешь взять таск и делать с ним, что хочешь

т.е. этот конкретно пример - это, скорее, отсутствие фичи, чем наличие

Да вместо .ressurect или прочих обработчиков ошибки

ну это всё частный случай одной большой фичи. того, что все запущенные корутины не линейный список.

так я не понял, в чём отличие то и инновация

про инновацию я просто написал, я так не считаю. просто от питоновских всё же котлиновские отличаются. такие же корутины со structured concurrency в го, вроде.

ну ещё раз, деревья есть и в зиво, и в токио и в питоне

Ээээ