Приветствую вас, читатели. Для начала я рекомендую вам ознакомиться с первой частью моего цикла статей.
В этом цикле я пишу о балансе, состояниях разработчика, корутинах и Dart.
Все части:
Об авторе
Меня зовут Антон, и я — чайный программист-даос.
Я 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 или не быть ?
Кто ты: хозяин своего мира или слуга своей вовлеченности ?
Спасибо за внимание !