AP
только за счёт порождения новых, да
Size: a a a
2021 June 01
AP
hot reload тоже так делается: старые куски дорабатывают параллельно с новыми, вторые постепенно вытесняют первые
AP
Вот, пишут, что кой-чего можно таки передать по сети: https://stackoverflow.com/questions/13660267/erlang-serialization
AP
"Можно, но не стоит" :)
MP
Может быть, уто удасться сделать в unisonweb через ability (алгебраические эффекты). Там стараются сделать все пересылаемым по сети, вполне возможно что континуейшены тоже пересылаются.
IR
это всё выглядит как лютый оверкил если честно
IR
"для workflow" не похоже на язык общего назначения. Возможно стоит раскрыть как это выглядит в действии.
AV
Мы делали свой недоязычок для чего-то похожего
AV
Точнее edsl в haskell
AV
Мой вывод - зря и надо было взять какое-нить lua, не лисп, поскольку правила надо было писать лютым императивщикам
AV
Или простигопсодипайтон
AV
Но в нём с сериализацией замыканий проблемы бы были и пришлось бы явные стейтмашины делать
IR
UE Blueprint
AV
У нас надо было слушать команды из кластера, отправлять всякие задачи дожидаться ответов, реагировать на события обрывающие вычисления и т.п.
2021 June 02
RN
Специфика воркфлоу - это сильно похоже на асинхронную и конкурентную программу, но переживающую свой рантайм много раз - бизнес процессы могут длится дни, недели или месяцы
RN
Ещё страшнее вопрос миграции процессов на новый флоу где нибудь в серединке
RN
Хочется вообще какого нибудь даталога
RN
Процесс состоит из многопоточного control flow и тасков, как асинхронных сериализованных вызовов функций
RN
Какой-то индемпотентный re-eval мнится
MP
Бизнес-процессы хорошо моделируются сетями Петри. Их стейт - просто набор натуральных чисел - числа фишек в каждой ячейки. И миграция при таком подходе не выглядит сверхсложной.