Приветствую вас, читатели. Для начала я рекомендую вам ознакомиться с первой частью моего цикла статей.
В этом цикле я пишу о балансе, состояниях разработчика, корутинах и Dart.
Все части:
Часть 1: О времени, сложности и мотивации: знакомство
Часть 2: О времени, сложности и мотивации: история поражения и победы
Часть 3: О времени, сложности и мотивации: финал

Об авторе

Меня зовут Антон, и я — чайный программист-даос.
Я 10 лет пишу код на разных языках, увлекаюсь даосизмом, китайским чаем и созданием никому не нужных (кроме меня) велосипедов.
Чуть подробнее обо мне тут.

О времени

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

Начнем со времени.

Сколько вы потратили на чтение этих статей в сумме ? Час ? Меньше ? А вот на реализацию виновника всего этого чтива у меня ушло около 6-7 месяцев.

Разумеется, это никак не 8 часов в день по 5 дней в неделю. Про такое я обычно говорю - "когда получалось, тогда и делал".

Но я все же оцениваю эту разработку в 6 месяцев. А чтобы пояснить причину, мне нужно привести свое определение для понятия "вовлеченность" и взаимосвязь этого понятия со временем.

Вовлеченность - это потеря пустоты, спокойствия, баланса и равновесия. Моя вовлеченность означает, что я отдал контроль над своими мыслями, своим "миром" кому-то другому. Человеку, процессу, идеи - просто кому-то.

Проблема вовлеченности в том, что она тебя гнетёт. Она разрушает. Она привязывает. Надоедает. И чем дольше ты вовлечен, тем сильнее ты получишь повреждения.

Теперь про вовлеченность и 6 месяцев. Все эти месяцы Dart не выходил у меня из головы. Жизнь шла сама собой, её нужно было как-то жить. Работу работать и все такое.

Но Dart... Он постоянно жужжал в сознании. А потом — "GC vs Anton: GC WIN! FATALITY!". И к вовлеченности добавились новые неприятные ощущения. Вот почему 6 месяцев.

В чем мораль ? Управляйте своим вниманием. Не позволяйте перейти ту грань, когда умеренное внимание превращается в безграничную вовлеченность. Потому что ваше время - это ваше внимание.

И да, Dart. Благодаря его архитектуре и особенностям кода я научился в каждом проекте, на каждом шаге оценивать степень своей вовлеченности.

О сложности

Кодили после работы? Если да, это состояние вам знакомо.

Утро: вы просыпаетесь, добираетесь до работы, с трудом входите в поток, ближе к вечеру выходите из него... и вам снова нужно погрузиться.

Другой проект, другой код, другой контекст — всё иное. Но вам нужно. Не потому что заставляют, а потому что, пока пишете свой код, чувствуете себя... иначе. Лучше.

В чём проблема?

Очевидно — в усталости. У вас просто нет ресурсов на новый код, особенно с таким переключением. Но допустим, вы нашли силы и сели работать ещё пару часов.

Возможны два сценария:

У вас был чёткий список задач. Вы его выполнили и со спокойной совестью пошли спать.
У вас был чёткий список задач. Но в процессе вы столкнулись с ним — жутким, плавающим багом.

Первый вариант — оптимистичный сценарий. Программист — молодец, всё сделал, отдыхает.

А второй? Три часа ночи, монитор слепит, вы прикидываете, сколько осталось до будильника и успеете ли выпить кофе перед работой. Узнаёте?

У меня были глупые, но забавные моменты: сидишь до 4 утра, злишься, идёшь спать, а утром за час фиксишь все баги. Почему? Потому что отдохнул.

Когда живёшь в таком режиме 10 лет (сначала учёба — ночной кодинг, потом работа — ночной кодинг), начинаешь замечать закономерности и искать решения.

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

Сложность в том, что нужно в нескольких местах зафиксировать изменения, связанные с одной задачей.

Сложность в том, что у тебя банально половина на Dart, половина на C++, и мозг постоянно переключает контекст (прям как процессор между корутинами, ага).

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

Сложность в конфигурациях сборки: по правде говоря, я не сразу смог заставить Dart в debug режиме показывать мне информацию по debug символам в запуске кода из VSCode.

Конечно, вы можете сказать: "А что ты хотел ? Ты зашел в чужой район, взял не свой вес, дружище", и будете правы.

Но сколько ещё мне таких "весов" нужно взять, прежде чем будет тот самый, последний, после которого я "сорву спину" ?

Или не я...

Пишите простой код, друзья, пишите простой код.

О мотивации

А вот с мотивацией все вообще просто. Она закончилась почти сразу :)

Серьезно, неужели вам показалось, что я горел огнем, когда ждал debug сборку по много минут. Ну, я-то горел, но не глазами. Или когда GC набил мне морду.

Кстати, про GC. Глупо получилось, вообще не спорю.

Надо было с самого начала разобраться в том, как работает GC в Dart.

А ещё в Tagged Objects, Write Barriers, recognized methods, external methods, native methods, stubs, runtime entries, instructions, snapshots, threads, isolates... ну вы поняли.

А вы думаете, мне это интересно ?

Разбираться в том, как работает другая технология, ради того, чтобы сделать то, что я уже давно представил в своей голове. Копаться в коде на плюсах, который вызывается из кода на Dart и генерирует код на языке ассемблера.

Вам в процессе прочтения показалось, что я испытал гамму прекрасных ощущений в процессе исследования абсолютно новой и непонятной предметной области ?

Нет её, мотивации. Закончилась, истончилась, пропала, потерялась, умерла, аннигилировалась, исчезла, испарилась, обесточилась и расщепилась.

Стоит здесь сказать такую вещь. Я правда люблю свою область, направление, программная инженерия и вот это вот все. Без любви я бы не стал копаться в таком объеме языков и делать все свои поделки.

Но вот эти исследования убивают все желание. Не у всех, разумеется. Есть те, кому в кайф вот именно исследовать. Такие люди ещё восхищаются той сложностью, про которую я выше писал. Но я не из таких, да и многие не из таких.

Мы хотим придумывать и реализовывать. Исследовать мы вынуждены.

Финал

Теперь пару слов про Dart без всяких философских характеристик. Ну и вывод надо бы сделать, какой-нибудь адекватный, да ?

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

Кстати, первую версию с GC багом можете почитать тут.

И кое-какие аспекты не реализованы совсем. Давайте расскажу о них. Список отсортирован в порядке важности с моей точки зрения.

JIT

Dart реализован в AOT и JIT режимах. Для AOT корутины работают, а в JIT нет.

Потому что в тот момент, когда мы меняем стеки корутин, нужно выполнить деоптимизацию кода при определенных условиях (я сделал такой вывод, изучая ResumeStub).

Debug

Допустим, мы сделали JIT и теперь можем отлаживать Dart с корутинами. Что будет, когда мы поставим точку останова на строчку Fiber.suspend ? Или на строчку после Fiber.suspend.

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

ARM и RISCV

Сейчас корутины работают под x64 архитектуру, но их нужно реализовать под все архитектуры, которые поддерживает Dart. Но делать это нужно после того, как на x64 заработают все фичи и будут нужные тесты.

Foreign Function Interface (FFI)

Мне очень хотелось бы видеть такие корутины, которые могут быть приостановлены в Dart и возобновлены в C, но это нужно сде��ать.

Оптимизация

В идеале я бы хотел взять 2-3 языка программирования, изучить особенности реализации корутин там, выявить недостатки в своей архитектуре, оптимизировать её.

Затем написать микробенчмарки, сформулировать критерии и локально оптимизировать код под них.

JS и WASM

Dart прекрасно работает в web. С корутинами вопрос открытый - а нужно ли ? Но тогда код будет не очень портабельным, так что в каком-то виде точно надо.

Upstream ?

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

Upstream, pull request, подведение API под спецификацию, вклад в OpenSource и так далее.

Да, нужно. Я согласен, нужно. Но давайте подумаем. Нужно кому ? Я не смог найти в сети какой-нибудь опросник, в котором Dart Team спрашивала у сообщества: "Вам корутины нужны ?".

В PR к спецификации было обсуждение этого вопроса, но я хочу спросить у Вселенной: а кто вообще решает, что нужно Dart и в каком виде ?

Нужно ли это лично мне ? 6 месяцев назад - очень сильно, сейчас - разве что та самая идея "каждый вносит свой вклад" не позволяет окончательно отбросить эту мысль. Но у меня есть сомнения касательно эффективности этой мысли.

Возможно, мои обстоятельства поменяются, и у меня появится достаточно мотивации сделать все эти фичи, актуализировать под upstream и выставить туда pull-request.
Главный вопрос - смогу ли я это сделать без вовлеченности ?

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

Так что да, я определенно вижу смысл в добавлении корутин в upstream. Но это я. А что же скажет мой уважаемый Читатель ? Быть корутинам в Dart или не быть ?

Кто ты: хозяин своего мира или слуга своей вовлеченности ?

Спасибо за внимание !