n
Да, я именно про это
Size: a a a
2021 May 18
Aß
тут есть нюансик
ŹR
Бим внутри по сути - микросервисная архитектура as is. А в твой микросервис может прийти любой запрос с любым payload - на этапе компиляции это не проверишь.
Е
Ну как это не знает? Ты отправляешь сообщение генсерверу не зная что делает этот генсервер и какие сообщения он может обработать?
Е
Ну так язык - это надстройка над BEAM
Aß
мы не можем проверить тип сообщения при компиляции, но мы можем проверить что обрабатываются все возможные сообщения
AF
Так генсервер это уже более высокая абстракция. Просто код приложения, соглашения не имеющие отношения к самому языку
ŹR
Весь ОТП нафик уйдёт просто
ŹR
Вместо этого получатся акторы как в пони
Е
Мы можем проверить, что ты не отправил этому вот генсерверу туфту, потому что знаем на этапе компиляции что именно он должен получить.
Е
Не получатся. В пони акторы практически ничего общего с процессами эрланга не имеют.
DR
Вот, кстати - я могу дать рекомендации всем компаниям, где работал - объяснить сильные стороны, что нравилось и почему ушёл и в каких случаях я бы рекомендовал и в каких не рекомендовал бы там работать.
Aß
мда, и как?
Е
Зная интерфейс этого генсервера.
DR
Почему бы не воспринимать - что процесс может получить любое сообщение и обязательно чтобы имел catch all клаузу? Проблема решена.
Aß
то есть ты предлагаешь параметризировать пиды типом принимаемых сообщений?
LL
Это было бы круто
ŹR
Ты не сможешь сделать handle_call к примеру в разрыве от api генсервера. Send в Пиды придётся запретить - потому что не проверишь. В результате акторы превратятся я жаба-лайк ооп
Е
Именно.
LL
Но только статическая типизация убивает весь хотрелоад