Вчера надо было приходить ?

Вчера надо было приходить ?

чуть разъехались по организации

но я планирую это исправить (надо только с ремонтом закончить, чтоб время появилось)

по голосовалке было человек 5, не считая инициаторов

По какой голосовалке?

Фомкин, ты придешь?

Хотя конечно по времени что-то поздновато...:(

По какой голосовалке?

Висела раньше

@optician_owl Ремонт дело такое, да

Скаланы есть вопрос, как мне на акторах сделать следущее. Есть список акторов, которые ожидают сообщение, и мне нужно, например, если это сообщение взял уже один из акторов(ну т.е. оно подошло ему по каким-то критериям), то остальным оно уже не отправляется. Чота я курю доку, вот как послать всем сообщение есть, понимаю как сделать, а вот как остановить рассылку что-то не доходит...

а распиши структуру и почему они все сообщения ждут ?

роутер?

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

Скорее реквестор

можно то по разному, можно шину бросить и остальным сообщать можно по таймауту

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

можно то по разному, можно шину бросить и остальным сообщать можно по таймауту

Что-то не понял кому другим сообщать?

Область значения предикатов акторов пересекается?

Или каждое сообщение подходит строго одному?

Что-то не понял кому другим сообщать?

чтобы не ждали же

у тебя n акторов ждут ответа

Звучит как не то что должно делаться акторами

Ну нет они должны ждать своих запросов

Или тебе надо каждого поочереди опрашивать: "а ты можешь?"

Не делай мультикаст, лучше воткни перед ними актор-роутер, который направляет сообщение ровно одному подходящему актору-обработчику.

Звучит как не то что должно делаться акторами

Гм может быть... Просто хотелось акторы пощупать

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

С акторами предикат просто дожен быть не внутри актора тогда уж

Не делай мультикаст, лучше воткни перед ними актор-роутер, который направляет сообщение ровно одному подходящему актору-обработчику.

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

Блин чорд...

Ну типо да

Угмс спасибки чота я заработался.... совсем голова не варит

Если хочешь начать продуктивно использовать акторы — забудь про мантру “все актор”.

Используй их только там где тебе нужна координация/линеаризация каких-то событий.

нетепизированные акторы - это ваще шаг в пхп какой то

Если хочешь начать продуктивно использовать акторы — забудь про мантру “все актор”.

Я уже начал подозревать, что, что-то тут не так :)

нетепизированные акторы - это ваще шаг в пхп какой то

а пацаны то не знали

Фомкин, ты придешь?

Так точно

нетепизированные акторы - это ваще шаг в пхп какой то

а можете мысль развить, очень интересно на какую проблемму все натыкаються с нетепизированными акторами что их ругают

Если религия не позволяет использовать нетипизированные акторы, то почему бы не взять Akka-Streams? ?

а можете мысль развить, очень интересно на какую проблемму все натыкаються с нетепизированными акторами что их ругают

Any => Unit ?

Any => Unit ?

а проблема в чем ?

Никаких гарантий в compile time.

Никаких гарантий в compile time.

теперь понял, спасибо

Это не значит, что акторы плохие. Они на несколько порядков лучше работы с локами/тредами и прочими классическими примитивами, но они все равно остаются очень низкоуровневой абстракций и по определению имеют побочные эффекты, поэтому лучше селить их где-то “на краю мира” вместе со всем остальным side-effectful кодом.

Это не значит, что акторы плохие. Они на несколько порядков лучше работы с локами/тредами и прочими классическими примитивами, но они все равно остаются очень низкоуровневой абстракций и по определению имеют побочные эффекты, поэтому лучше селить их где-то “на краю мира” вместе со всем остальным side-effectful кодом.

Ну да, я их использую только для синхронизаций

Но зачастую и это оверкилл

Это не значит, что акторы плохие. Они на несколько порядков лучше работы с локами/тредами и прочими классическими примитивами, но они все равно остаются очень низкоуровневой абстракций и по определению имеют побочные эффекты, поэтому лучше селить их где-то “на краю мира” вместе со всем остальным side-effectful кодом.

Сейчас должен ворваться Олег и рассказать за моникс и на сколько порядков что чего лучше

А чего тут врываться. Actors > Threads, Monix > Actors.

У акторов еще есть location transparency

А чего тут врываться. Actors > Threads, Monix > Actors.

Я бы с акторами моникс не сравнивал. Акторы - это про состояние. Я бы скорее Моникс с фьючерами сравнивал и Akka Streams.

У акторов еще есть location transparency

что делает их немного другим классом примитивов

А их и не надо сравнивать по метрике “кто круче”. В реальном приложении у тебя будет все вперемешку. Чем больше гибкость, тем меньше гарантий. Для каждой задачи надо выбрать подходящую абстракцию по principle of least powerful abstraction.

Классическая статья: https://www.chrisstucchio.com/blog/2013/actors_vs_futures.html

Тут не про акторы, но это вообще полезный принцип: http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html

Я бы с акторами моникс не сравнивал. Акторы - это про состояние. Я бы скорее Моникс с фьючерами сравнивал и Akka Streams.

моникс норм про состояние

МВары с обсёрваблами вытеснили акторы, упростив и ускорив код в большинстве мест у меня

МВары с обсёрваблами вытеснили акторы, упростив и ускорив код в большинстве мест у меня

а можно чуть больше информации про ускорение, насколько выросла скорость работы ?

А есть Mvar-Persistence? ?

А есть Mvar-Persistence? ?

Есть. "ru.tinkoff" %% "cassandra-persist" % "0.9.0"

Ну или там hazelcast

Ну или там hazelcast

?

а можно чуть больше информации про ускорение, насколько выросла скорость работы ?

Мерял не очень много. Был один кусок, где грубо говоря на акторах расшаренная двусторонняя мапа с TTL была. Я её не очень оптимизировал м записи в неё складывались поштучно, а на запрос нужно было сложить пару сотен. Это конкретно место ускорилось в десять - сорок раз.

нашел 1 доку и 0 видео на youtube без упоминания haskell, ScalaAsBetterJava джедаи ниасилят

Мерял не очень много. Был один кусок, где грубо говоря на акторах расшаренная двусторонняя мапа с TTL была. Я её не очень оптимизировал м записи в неё складывались поштучно, а на запрос нужно было сложить пару сотен. Это конкретно место ускорилось в десять - сорок раз.

А запрос через ask pattern был?

На самом деле моникс простой как пробка. В сто раз проще акки. Ну и когда у тебя есть потребность ремоут, кластер или вон персистенс, его не покроет

А запрос через ask pattern был?

Канеш

На самом деле моникс простой как пробка. В сто раз проще акки. Ну и когда у тебя есть потребность ремоут, кластер или вон персистенс, его не покроет

а как вкатываться то ? что читать и что смотреть если далек от мира хаскеля ?

https://monix.io ?

а как вкатываться то ? что читать и что смотреть если далек от мира хаскеля ?

Не знаю, зачем хаскель там. Читаешь оф доку. Пробуешб заменить фьючи на таски и дальше всё само идёт

Канеш

В акторах в этом случае делают обычно eventually consistent слушателя. То есть пишут через актор, а читают напрямую. Получается... MVar.

Там отличная дока.

а как вкатываться то ? что читать и что смотреть если далек от мира хаскеля ?

Monix простой действительно очень, там не нужен хаскель. Проще акки.

https://monix.io ?

я по MVar гуглил

В акторах в этом случае делают обычно eventually consistent слушателя. То есть пишут через актор, а читают напрямую. Получается... MVar.

Нет. Не получается.MVar можно и консистентно

я по MVar гуглил

https://monix.io/docs/2x/eval/mvar.html

В моём случае нужно было обязательно узнать результат из актора

В моём случае нужно было обязательно узнать результат из актора

я запутался

https://monix.io/docs/2x/eval/mvar.html

я о том и писал, что scala mvar - одна валидная статья

Да простой он очень этот Моникс. Типа как Akka-Streams, но для плебса и без матерализеров :D И то, и другое имеет право быть, а ещё и отлично интегрируется через reactive-streams.

я запутался

В Мапу складывается контент, чтобы контент два раза не складывать в акторе генерится ему ключик, либо возвращается ключик уже имеющегося. Этот ключик нужен потребителю

В акторах в этом случае делают обычно eventually consistent слушателя. То есть пишут через актор, а читают напрямую. Получается... MVar.

Получается не MVar, а agent в терминах кложи. Такое тоже есть. Но МВар умеет и синхронное чтение

В Мапу складывается контент, чтобы контент два раза не складывать в акторе генерится ему ключик, либо возвращается ключик уже имеющегося. Этот ключик нужен потребителю

А это не кеш случаем?

Да простой он очень этот Моникс. Типа как Akka-Streams, но для плебса и без матерализеров :D И то, и другое имеет право быть, а ещё и отлично интегрируется через reactive-streams.

Без org.reactivestreams ещё проще интенрируется

А это не кеш случаем?

Нет

Не видел, чтобы в кешах генерились ключики после того, как контент уже естт

Не видел, чтобы в кешах генерились ключики после того, как контент уже естт

То есть ключ у мапы - это контент, а значение - это сгененированный ключ?

Это кокеш какой-то

То есть ключ у мапы - это контент, а значение - это сгененированный ключ?

Ну я упоминал, что мапа двусторонняя. Т.е. есть и в ту и в другую ключ-значение

Грубо говоря, нужно для контента получить короткий айдишник. Или вернуть имеющийся, если есть

iкеш тогда

я просто недавно читал scala-with-cats))

iкеш тогда

я имел в виду, что key --[probably cached]-> value заменено на key <-[probably cached]-- value

Звучит как обычный кеш от content в key.

а. понятно, мне показалось в обе стороны

Звучит как обычный кеш от content в key.

поподробнее