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

Вот ещё
https://www.erlang-solutions.com/blog/receiving-messages-in-elixir-or-a-few-things-you-need-to-know-in-order-to-avoid-performance-issues.html
Начиная со слов "The cost of using a selective receives"

Так всем известно что selective receive это не сильно оптимальное место

mailbox в erlang-е это не про хранение сообщений для обработки, а просто про некоторый ордеринг твоих сообщений

Если у твоего процесса mailbox стабильно имеет размер больше десяти, то лучше переходить на pull модель

Ну типа, использовать mailbox процесса как место для хранения сообщений перед обработкой — очень плохое решение

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

тогда это какой то антипатерн

gen stage c каким нибудь пулом воркеров с приоритетами

В rabbitmq, как я понял, отказались от selective receive, потому что они там работают напрямую с tcp-сокетом, который может послать кучу сообщений разом

Нет, не антипаттерн. selective receive хорошо работает на маленьких очередях

> Если у твоего процесса mailbox стабильно имеет размер больше десяти

При проектировании может быть неочевидно, какой будет размер мэйлбокса, и как он скаканёт завтра. И тогда вместо гарантий, которых хочется от BEAM, мы будем иметь потенциальную проблему.

Ничего не понял. Если ты не можешь спрогнозировать и используешь selective receive, то это твоя проблема

Я лично использую selective receive в процессах, где сообщения присылаются часто и обрабатываются быстро. Ещё я нередко ставлю этим процессам приоритет повыше

ну в итоге то,  если вдруг туда прилетит 100500 сообщение разом, то он превратится в тыкву?

Я перезалил видос https://www.youtube.com/watch?v=IJ8g05Fn4lU

Со звуком

А, блин. не сюда надо

в ОТП не поддерживается selective receive потому, что
A selective receive cannot be used from a gen_statem behaviour (or from any gen_* behaviour), as the receive statement is within the gen_* engine itself. It must be there because all sys compatible behaviours must respond to system messages and therefore do that in their engine receive loop, passing non-system messages to the callback module.

Но, заметьте, что
The transition action postpone is designed to model selective receives. A selective receive implicitly postpones any not received events, but the postpone transition action explicitly postpones one received event.
Both mechanisms have the same theoretical time and memory complexity, while the selective receive language construct has smaller constant factors.

То если вам в ОТП нужен selective receive, то из коробки смоделировать такое вы можете через gen_statem

В gen_statem нет selective receive, это просто тот же самый gen_server, только с парой приятных штучек