Comments 43
Если кто хочет поучаствовать в разработке, — вот нужный, пока отсутствующий, кусок: https://github.com/am-kantox/joerl/issues/1
карму мне скоро выкрутят в минус
Удивительно, правда?
Вы вещаете из глубокого технологического колодца и ваше бубнение непонятно здешней публике. А адаптироваться вы не хотите.
Что еще нужно?
Демонстрации по бизнес ориентированным задачам. Тут только техно демки, proof of concept для тех кто и без того хорошо разбирается, то есть для ерланг программистов. А таковых тут нет
А адаптироваться вы не хотите.
Да пошла эта публика, не понимающая технологий, на три весёлых буквы.
Удивительно, правда?
Нет, не удивительно. Но есть вещи, к которым не надо адаптироваться.
А вообще, путь адаптаций, он может очень далеко завести...
Именно. Я даже думал взять ник «Randle McMurphy» но это было бы слишком претенциозно.
У хабра в последние 15 лет есть очень опасная тенденция: здесь слишком поощряется серость. Чем ты усредненнее, тем лучше. Особенно, если ты не высовываешься, делаешь вид, что вежлив и даже чуточку интеллигентен, и если ты умеешь восемь раз в одном комментарии обосновать, что белое белее черного, а черное — чернее белого.
Я ненавижу за такой позорный тип поведения советскую интеллигенцию и борюсь с ним по мере сил в свободное от написания текстов время. За любой голос против — тебя сожрёт не ужасное КГБ, а твои же соседи, под самыми благовидными предлогами.
Назовите хоть одну причину, по которой мне имело бы смысл адаптироваться.
А таковых тут нет.
Как однажды сказал Наум Коржавин на форуме славистов: «Я пишу не для славистов, я пишу для нормальных людей». Я публикую тексты здесь с единственной целью: сделать их подоступнее в поиске. Продавать правильную архитектуру людям, которые лучше горутин в своей жизни ничего не видели — мне неинтересно. Я не миссионер, не евангелист, не популяризатор и не коммивояжер.
Я думаю карму скорее сливают за вот такие комментарии.
Сообщения принципиально сделаны
type-erased— и позволяют отправлять что угодно; я не считаю типы — полезной херней.
Если я правильно помню, там проблема в том, что сообщения могут быть пересланы дальше, так? Соответственно, типизация должна быть как-то ослаблена. А вот «классы типов» там не подойдут? То есть, актор А принимает сообщения, реализующие trait Atrait, а актор Бэ — Бtrait. Хотя всё равно, хочется иметь переконфигурируемую сеть, но, кажется, всё не так уж и плохо получается?
А есть ещё gradual typing.
Микросервисы пересылают самодокументированный JSON, так и тут должно быть
Там проблема хуже. Набор сообщений, который автор готов обрабатывать динамически меняется со временем. При том, это буквально базовый функционал. Допустим актор A послал сообещние-запрос в автор B. Тогда после этого актор A умеет обрабатывать одно сообщение BReply — как только он его получит, он потеряет возможность обрабатывать сообщения BReply.
Разумеется, правда, все эти проблемы проявляются только в авторах с нетривиальным поток управления. Когда авторы задаются через трейты — проблему обходят просто заставляя пользователя ручками делать конечный автомат и перечислять все функции, которые автор может вызвать...
Где «там»?
Акторы у меня задаются через трейты и от сообщений требуется реализация трейта сериализации. И это всё никак не отменяет, что я смотрю на мир шире своей песочницы и хочу уметь подружить в одном кластере ноды на эрланге и ноды на расте, причем нативно.
Там — в типизации акторных систем.
Я понял, что акторы у Вас задаются трейтами. Но как уже сказал, это весьма неприятный способ задания акторов. Сравните с тем же send/receive в эрланге — там акторы это код.
А, ну да. Но, насколько могу судить, я прошел по тонкой косе между двух волн: в раст тащить прям динамический подход эрланга — это перебор, но и приколачивать гвоздями типы сообщений, как это делает actix — не вариант.
Я попытался оставаться пока возможно в парадигме раста, но для сообщений — это суицид. Поэтому вот так.
Я не согласен. Возможность сделать receive где-то глубоко внутри обработчика GenServer, имхо, фундаментально важна. Это окей, если Вы предоставляете трейты в качестве сахара, но если нет возможности сделать динамический receive — это убивает лвиную долю затеи.
Основная проблема в том, что Вы даже GenServer не сможете сделать без receive. Потому что GenServer.call должен сделать receive и получить ответ. Понятное дело, что можно зашить GenServer в ядро — но это не решает проблемы пользовательских паттернов взаимодействия (как сделать несколько параллельных вызовов генсерверов?;))
И нет, receive можно перенести в раст почти один в один как в эрланге. У меня был рабочий прототип (даже с пм по сообщениям) с семантикой эрланговских акторов. Всё никак не нахожу времени, чтобы довести его до ума.
сделать receive где-то глубоко внутри обработчика GenServer, имхо, фундаментально важна
Если вы приведете живой пример, мне будет гораздо легче понять, зачем. Пока мне это не очевидно.
Гораздо важнее, на мой взгляд, поддержка :noreply в качестве ответа на call и эксплицитного вызова reply/2 когда-нибудь потом. А у меня и её пока нет.
receive можно перенести в раст почти один в один как в эрланге
Наверняка, и я даже мог бы взяться (после отложенного ответа), если бы понимал, в какой ситуации это необходимо. Пока мне кажется, чем всё прикладное буквально можно реализовать на абсолютно асинхронных вызовах без прямого вызова receive. Но я запросто могу быть просто слепым (или забывчивым) в данном случае.
Ну, я же говорю, что это абсолютно нужно для реализации кастомных паттернов. Банальная задача: сделать два вызова сервера параллельно. В эрланге делается просто: отправляем два сообщения на запросы (call), после чего делаем два receive. А вот в модели трейтов, тут сложнее — нужно прыгать прям до основного ивент-лупа, там получать эти сообщения и дальше продолжать исполнение обработчика. Абсолютно лишняя сложность.
отправляем два сообщения на запросы (call), после чего делаем два receive
Наверное, речь не про call а как раз про ! уровнем ниже gen_server, но я понял. В эрланге (и в моей библиотеке до последней версии) я это реализую двумя :gen_server.cast/2 с передачей собственного пида, или двумя :gen_server.call/2, которые мгновенно вернут {:noreply, _}, попутно запустив асинхронную функцию, куда будет передан from. А те уже вызовут reply/2 когда им вздумается.
Ну, два cast требуют переписывать сервера под потребителей. А так, можно сделать два call одновременно (да, через сырую отправку, увы). Тут даже noreply не нужен (если например вызовы к разным авторам, или если мы боремся с rtt).
Возможность селективного receive это очень важная фишка, которую многие акторные фреймворки забывают сделать, увы.
В общем, я психанул и реализовал selective receive и deferred replies.
Вот примеры: selective receive, deferred reply.
receive из эрланга более-менее адекватно в раст перенести не получится, но ведь и в самом эрланге сегодня им пользуется только сам Вирдинг :)
А gen_server и gen_statem я затащил.
В принципе, в вакууме никакой проблемы нет. actix, который, насколько я понял, является «стандартной» реализацией акторной модели в расте, естественно, строго типизирует все сообщения.
Но я приложил некоторое количество усилий к тому, чтобы кластер мог быть гетерогенным. На данный момент, мой epmd — обслуживает, конечно, только мои же ноды, но даже из названия понятно, что вместо этой заглушки я хочу в результате использовать родной эрланговский. У меня банально не хватило сил и времени по уму разрулить анбоксинг, но код полностью к этому готов.
Если бы я завязался на хоть какую-то типизацию — прозрачно воткнуть три ноды на расте в отипишный кластер не удалось бы никогда.
У меня банально не хватило сил и времени по уму разрулить анбоксинг, но код полностью к этому готов.
Вот, кстати, "дико плюсую" за "по уму". Сам-то ETF простой как три копейки... но вот дальше.
В принципе, в вакууме никакой проблемы нет.
Там есть большие проблемы — было много попыток ввести типизацию сообщений в акторную модель, все провалились. Кмк, нужна какая-то хитрая система типов, которая позволит не терять гибкость.
Завтипов должно хватить, насколько могу судить.
Да, в том смысле, что на них можно просто прочекать весь мир. Но нет, потому что это практически неюзабельно.
Даже на взаимодействии двух акторов слишком часто приходиться закатывать солнце вручную. Я уже не говорю про всякие интересные правила типа "после того, как я получил сообщение W от актора X, я могу отправлять сообщение M всем авторам из группы G, но всего, не более чем 3 раза". Ну и там, по-хорошему, нужны линтипы для моделирования сообщений, которые можно отправить лишь некоторое количество раз.
Без линтипов, там нужно всех акторов запихивать в одну огромную монаду и трекать набор доступных сообщений в её типе. И то есть сложности...
Что еще нужно?
Registry из Elixir. Хотя, его можно и свой написать.
@cupraer библиотека выглядит здóрово.
Зачем нужно было публиковать статью про свою библиотеку во второй раз, не добавив при этом ничего полезного?
Отлично получилось, в целом. Осталось реализовать ETF (ну и ещё "койчего") и можно цепляться как external node к.
Если кто хочет поучаствовать в разработке, — вот нужный, пока отсутствующий, кусок: https://github.com/am-kantox/joerl/issues/1
joerl :: довёл до рабочей версии