Прям лонг рид описывающий существующие модели ошибок в ЯП, и подход выбранный в экспериментальном ЯП для экспреминтальной ОС от МС.

ну и главный посыл: нужно 2 механизма - незаметный фейл фаст для багов и заметный для ошибок в окружении

http://joeduffyblog.com/2016/02/07/the-error-model/

#ergo_approach@ergonomic_code #error_handling@ergonomic_code

Kotlin Result DSL

Эдит: вариант для чтения на мобилках

И кстати в догонку про обработку ошибок.

Я в своё время прям сильно впечатлился Rust-овским try! (Который уже оказывается стал ?-оператором)

И недавно запилил драфт похожей штуки для Котлина:

fun testReturn(): WorkflowResult<Int, Throwable> {
    val int = doIo()
        .onError { return it }
    return Result(int + 1)
}

Это аналог вот такому коду:

fun testLong(): WorkflowResult<Int, Throwable> {
    val res = doIo()
    if (res is Error) {
        return res
    }
    val int = (res as Success).result

    return Result(int + 1)
}

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

Но спрашивается зачем всё это?

В Котлине возврат того или иного Result - это единственный способ явно показать вызывающему коду, что функция может ошибиться. А очевидность вообще и очевидность мест где что-то может пойти не так - это основа эргономичного кода.
Но если это делать наивно, то получается код как из втрого примера.

Вообще Result-ы как правило являются монадами и с ними можно работать так:

    val res = doIo()
    return res.map { it + 1}

И так получается даже короче. Но в Котлине нет спец синтаксиса для монад и поэтому они не масштабируются.
Например, если надо выполнить ИО-операцию на базе результата первых двух (и только в случае их успеха), то будет вот такой адок:

fun testCompositeM(): Optional<Int> {
    val first = mIo()
    val second = first.flatMap { mIo2(it) }
    return first.flatMap { firstVal ->
        second.flatMap { secondVal ->
            mIo2(firstVal + secondVal)
        }
    }
}

С моим же DSL-ем, всё будет прилично:

fun testComposite(): WorkflowResult<Int, Throwable> {
    val first = doIo().onError { return it }
    val second = doIo2(first).onError { return it }
    return doIo2(first + second)
}

Полный код DSLя

#error_handlin@ergonomic_code #kotlin@ergonomic_code #posts@ergonomic_code #ergo_approach@ergonomic_code

Друзья!

В первую очередь хочу ещё раз поблагодарить вас за то что подписались - я очень рад, что набралось больше 3-ёх человек:)

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

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

В ближайшие месяц-два посты будут трёх типов:
1) каждый вторник я буду стараться выкладывать авторские посты об Эргономичном Подходе и актуальном личном опыте;
2) каждый четверг я буду постить хёртбитную-ссылку на людей, книги, научные и популярные статьи и презентации, которые меня впечатлили в прошлом;
3) 0-2 раза в неделю я буду постить ссылки на какие-то актуальные статьи, показавшиеся мне интересными.

т.к. начало было сумбурным, и Kotlin Result DSL - это вообще приложение к одной из концепций ЭП (Workflows), то в ближайшие недели я буду писать предисторию к этому приложению:)
Пока план постов такой:
1) Эффекты, сайд эффекты и чистые функции. Что это за звери, чем отличаются, чем хороши и чем плохи;
2) Локальность рассуждений о коде (Local reasoning). Что это такое, почему важно;
3) Широкий и глубокий код. Нас учили, что функции должны быть короткими - это не всегда так. Локальность рассуждений важнее;
4) Workflows. Засунуть всё в одну функцию - тоже не вариант. Решение - воркфловы - шаблон разбиения кода, реализующего верхнеуровневую операцию с сохранением локальности рассуждений;
5) Kotlin Result DSL - применение Kotlin Result DSL для повышения эргономичности воркфловов.

Что именно будет потом - пока не знаю.
Может вы уже все разбежитесь:)
Но если не разбежитесь, то я накидал список из 7 потенциальных тем, многие из которых так же могут развернуться в несколько постов.
Так же посмотрю ещё, но возможно буду разбавлять циклы посвящённые одной теме какими-то актуальными и горячими находками и идеями.
В общем я знаю о чём писать в ближайший год:)

P.S.

Ставьте лайкипишите комменты:)

#ergo_approach@ergonomic_code

Хорошие книги: Designing Data-Intensive Applications

Привет!

Четверговые посты начну с рубрики "хорошие книги".

А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications.

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

Designing Data-Intensive Applications - это приложения которые упираются не в CPU, а в количество, скорость поступления или сложность данных.
Т.е. считай все бэки.

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

Рекомендую бакэндерам всех уровней - юниорам просто как введение в разработку, сеньёрам - как способ лучше структурировать знания по теме (да и хоть что-то новое тоже наверняка найдёте).
Своим юниорам на бэках я точно буду экзамен по этой книге проводить:)

Для фронтэндеров тоже есть практически полезная 4-ая глава о форматах взаимодействия бэка и фронта и его версионирования.

#books@ergonomic_code #databases@ergonomic_code