не понимаю, зачем Де Гоуз поверх скалаз своё IO сделал

кстати, я правильно понимаю, что более используемой реализацией фп является cats?

‘реализация фп’ :/

Ну да коты сейчас во всех новых либах

не понимаю, зачем Де Гоуз поверх скалаз своё IO сделал

Потому что мир несовершенен, зачем много джейсон библиотек

кто-нибудь портирует на котов, безо всех этих \/

кто-нибудь портирует на котов, безо всех этих \/

\/ уже сто лет нету

кто-нибудь портирует на котов, безо всех этих \/

а как вы обычно гуглите скалаз/хаскел имена?

\/ уже сто лет нету

да ладно? В презентации Де Гоуза про его IO - есть.

да ладно? В презентации Де Гоуза про его IO - есть.

В котах

при чём тут коты?

при чём тут коты?

А причем тут дизъюнкция?

А причем тут дизъюнкция?

она используется в апи scalaz 8 IO

user facing

она используется в апи scalaz 8 IO

Там в комментариях реализации дизюнкции сказано почему она осталась пока

осталась в scalaz или IO?

везде, они хотят поддерживать не только скалу 2.12

правая она, это важно

ну коты же поддерживают не только 2.12, там имплиситами это корректируется, правость в смысле

Два мнения просто, вот поэтому и есть коты, скалаз и дегоз пилит скалаз 8, сам же отвечаешь на свои вопросы

не понимаю, о чём ты :)

кто-нибудь портирует на котов, безо всех этих \/

Про это

это не вопрос

А что это вообще значит тогда?

что кому-то пора спать, не иначе!

не понимаю, зачем Де Гоуз поверх скалаз своё IO сделал

Все началось с этого, вот я и подвожу к тому, что не зря делает, возможно

кто-нибудь портирует на котов, безо всех этих \/

\/- и -\/ еще не забудьте)

.\m/

годик?

Пулреквест уже смержили

Он походу уже устарел, нынче ‘data IO e a’ в почете

Пулреквест уже смержили

а остальное scalaz 8? Оно же не состоит из одного IO. Надо как минимум старый кривой Task/IO выкинуть

скаланы, кто-нибудь сталкивался с такой бедой в IDEA https://gist.github.com/atapin/2f23392302d487074e975e1353f4f992 ?

А версия сбт какая?

А версия сбт какая?

1.0.4

оказалось, что IDEA была натравлена на устаревший JDK

Выше 1.0.4 она ещё и в принципе не поддерживает (хотя мб поправили)

Ребят, в scalaz была штука типа bool.option(…..), а в cats что-то не вижу подобного

.some ? или что option(..) делает?

типа если true то оборачивает в Some то что передаешь в option, если - false, то None

Как-то сомнительно выглядит

Ребят, в scalaz была штука типа bool.option(…..), а в cats что-то не вижу подобного

тебе нужен https://github.com/typelevel/mouse

да, оно самое

Ребята вопрос: Есть три актора Клиетн Парсер и Сервис авторизации. Клиет посылает сообщение Парсеру тот конвертирут в комадны и посылает ее тому кто может ее обработать в нашем слечае сервису авторизации. Вопрос кому Сервис авторизации должен отвечать Парсеру или Клиенту?

Ребята вопрос: Есть три актора Клиетн Парсер и Сервис авторизации. Клиет посылает сообщение Парсеру тот конвертирут в комадны и посылает ее тому кто может ее обработать в нашем слечае сервису авторизации. Вопрос кому Сервис авторизации должен отвечать Парсеру или Клиенту?

По идее, отвечать он должен тому, кому это сообщение нужно

Ребята вопрос: Есть три актора Клиетн Парсер и Сервис авторизации. Клиет посылает сообщение Парсеру тот конвертирут в комадны и посылает ее тому кто может ее обработать в нашем слечае сервису авторизации. Вопрос кому Сервис авторизации должен отвечать Парсеру или Клиенту?

Парсеру, а парсер клиенту

Парсеру, а парсер клиенту

Зачем гонять сообщения по лишней цепочке? Если эти акторы вечно живущие, то нет в этом смысла.

Зачем гонять сообщения по лишней цепочке? Если эти акторы вечно живущие, то нет в этом смысла.

Разделение на слои и выделение границ в системе играет значение. Если добавится больше акторов, то может стать сложнее.

типа если true то оборачивает в Some то что передаешь в option, если - false, то None

в 2.13 кстати добавили https://github.com/scala/scala/blob/2.13.x/src/library/scala/Option.scala#L36

круть

Разделение на слои и выделение границ в системе играет значение. Если добавится больше акторов, то может стать сложнее.

Какие слои в трёх акторах? Добавляй тогда сразу туда кафку, сервис дискавери и еще кучу всего... а вдруг понадобится))

Ребята вопрос: Есть три актора Клиетн Парсер и Сервис авторизации. Клиет посылает сообщение Парсеру тот конвертирут в комадны и посылает ее тому кто может ее обработать в нашем слечае сервису авторизации. Вопрос кому Сервис авторизации должен отвечать Парсеру или Клиенту?

если парсер - просто перегонет один формат в другой - то он может быть не актором, и тогда никаких заморочек

Какие слои в трёх акторах? Добавляй тогда сразу туда кафку, сервис дискавери и еще кучу всего... а вдруг понадобится))

Обычно все начинается с 3 акторов, а потом заканчивается энтерпрайзом же) И вообще там написано было "сервис авторизации". Такие сервисы всегда плотно изолируются и у них должен быть trusted boundary, в данном случае парсер в него может войти, а клиенты нет

Ребята вопрос: Есть три актора Клиетн Парсер и Сервис авторизации. Клиет посылает сообщение Парсеру тот конвертирут в комадны и посылает ее тому кто может ее обработать в нашем слечае сервису авторизации. Вопрос кому Сервис авторизации должен отвечать Парсеру или Клиенту?

используй forward и конечный актор ответит первичному

используй forward и конечный актор ответит первичному

оно раздувается на самом деле

оно раздувается на самом деле

в каком смысле раздувается ?

просто нужно помнить, что скажем, аск порождает актор дополнительный

в каком смысле раздувается ?

ну если у тебя потом сущности добавятся, то потом будет очень тяжело сказать, что и как отвечает

ну если у тебя потом сущности добавятся, то потом будет очень тяжело сказать, что и как отвечает

это нюанс

в топку акторы, куда проще определить трейты с понятными интерфейсами и дергать нормальные методы

ну как бы , да, по это стоит помнить

спрячь акторы за них и никому не показывай

в топку акторы, куда проще определить трейты с понятными интерфейсами и дергать нормальные методы

не в топку

очень удобно

когда есть стейт какой-то

акторы оч удобны

ERROR: S client not available

ну а какой там стейт то

все равно все из базы читаться будет

акторы хороши когда тебе нужна linearizability с определенным scope

а если весь стейт в базе то непонятно для чего пихать лишние сущности

нет mutable стэйта in-memory - акторы не нужны

нет mutable стэйта in-memory - акторы не нужны

во

к тому же у акторов бекпреши нет

из коробки

началось, сегодня не нужны акторы а завтра что? mongodb не нужна?

сам сделай

к тому же у акторов бекпреши нет

да и пусть падает

лол

да и за бекпрешу ты платишь не хило так

уж лучше платить за бекпрешу чем положить сервис от OOM

уж лучше платить за бекпрешу чем положить сервис от OOM

реальный опыт?

да

да

расскажи что как было, в назидание потомкам пжлста

уж лучше платить за бекпрешу чем положить сервис от OOM

ну так

типа

лет ит креш

добавь ноду

оом у тебя произойдет где0-нибудь в другом месте

лет ит креш

боюсь у меня не тот кейс когда можно крешится

типа кафка переполнится и станет удалять необработанное

или еще что нибудь

боюсь у меня не тот кейс когда можно крешится

ПЕРСИСТЕНТ АККА

ПЕРСИСТЕНТ АККА

ну ее тоже не везде же можно применять :)

ну тож как бы

но проблемы с ООМ надуманы

добавь ноду

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

но проблемы с ООМ надуманы

мой опыт говорит об обратном :)

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

ну смотри, кривой код это кривой код, просто вот говорят бекпреша, но ты как бы повышаешь во-первых стоимость ресурсов, во - вторых перекладываешь задачу хранить поток событий на что-то верхнеуровневое, и в любом случае тебе ноду добавлять если очередь перманентно растёт