Вот благодаря промо от ДД и заплатил им😂

А он что на расте написан?

Точно, надо пойти обвалить им рейтинг с RIIR негативными обзорами!)

ам, в смысле?)

так он таки на гейммейкере? я просто не понял почему ты скинул его :)

не пойму почему статью написать нельзя 😢 или транскрипт

слушать подкасты нет никаких сил

Хз, я сюда время от времени просто про игровые штуки всякое кидаю.

Как правильно изменить версию либы если ее зависимость тоже увеличила версию и при это она экспортируется в апи основной либы? Более кратко dependency: 0.1.0 -> 0.2.0 тогда main: 0.1.0 -> ?

должно ли это быть main: 0.1.0 -> 0.2.0 или main: 0.1.0 -> 0.1.1 ?

Первое

отлично, спасибо

@ozkriff там в дискорде авария лол

мда. Вроде пришли крутые челы, вон репи пришел и начался такой детский сад :\

Такое

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

О, похвально, считаю Rust для таких целей идеальным!)) А на счет Addr::send что вас смущает? Это сродни обычной системе ивентов, хотите - делаете безответные события, хотите - вешаете колбеки на события, можно и так и так. Только если вам таки нужен результат выполнения, и вы не через send сделали, а например через do_send, то когда этот актор закончит выполнение задачи, ему нужно или знать address куда отослать значение, или общий актер-роутер (у которого ссылки на все акторы) должен понимать кому передать. А если через Addr::send отослано было, то и как бы не нужно думать о том, куда потом этот результат слать :)

У меня схема какая.
Есть актор который живет как websocket handler
У него есть пара, которая отслеживает состояние клиента.
Они друг о друге знают и шлют друг другу сообщения безответные

А есть актор который работает как фасад для внешнего сервиса.
Ему логичней было бы send делать и ответ от сервиса отдавать.
Но сервис сначала по HTTP отвечает, а потом еще хук дергает.
Поэтому одним `send`ом не сразу понятно было как обойтись.
Но в итоге сделал с одним `send`ом, результат которого резолвится либо сразу с ошибкой, либо с ошибкой из ответа от внешнего сервиса, либо когда уже хук вызовется, ну или по таймауту

Ну вы можете смотреть на акторов как на сущность, которая умеет принимать события по некоему наружу выданному параметру, называемому адрес. Имея этот адрес, можно отправить событие актору.
Все дальнейшие мысли о том, как построить архитектуру строится ровно на этом понимании.
Касательно вашей ситуации: У вас извне приходит реквест, во время реквеста вы не можете просто так отослать фасаду событие и как-то его потом слушать, просто потому что зачем тогда актор-фасад 😄 Значит вы должны спросить у него и получить ответ от него же, поэтому очень логично использовать send. А уже внутри этого фасада можно реаизовать последовательность футур, каждая из которых будет делать свои дела. Иначе можно было эту последовательность футур запустить вместо фасада - тогда можно было бы поидее без фасада обойтись 😏

Фасад тут нужен только что б состояние выполнения этих футур хранить

А хуку нужна единая точка доступа

Акторов, которые делают запрос на внешний сервис много. А хук один на всех