Здравствуйте, LaPerouse, Вы писали:

LP>3. Асинхронный код сложнее в поддержке, это все знают.

Я предлагаю отказаться от выражения "асинхронный код", разделив его на два — "лапшеобразный код" и "асинхронная логика".

Так вот, лапшеобразный код, тут я согласен, сложнее в поддержке. Однако, выразить "асинхронную логику" с помощью обычного (без колбэков и монад) можно с помощью стековых корутин. Вот пример. Если он понятен и присутствие yield не смущает, то дальше можно не читать.

Если код использует полиморфизм (например, как в iostreams, IStream (это из COM) или даже С-шный minizip), то его логика может выполняться асинхронно. Например, двадцать лет назад был написан и скомпилирован, а после компиляции безвозвратно потерян вот этот блокирующий (псевдо)код:

result read_from_stream(stream s)
{
    while(s.is_good())
    {
        s.read();
    };
    return result(...);
}

Понятное дело, что пока не прочитается весь поток (а это может занять хоть неделю), мы не сможем обрабатывать другие запросы. Правда? Конечно нет! Достаточно запустить эту функцию внутри корутины, передав такой stream, который в своей функции read не будет дожидаться окончания чтения, а вместо этого только быстренько запустит чтение и сразу же yield-нется на корутине. Через неделю, когда чтение закончится, нужно не забыть переключиться обратно в корутину, чтобы продолжить выполнение с того места, где мы прервались в прошлый раз.

Теперь только остаётся отказаться от выражения "блокирующий код", т.к. оно вовсе лишено смысла (выше я применил его, чтобы было легче читать. Это помогло?).