я бы согласился с ним в том что 90% можно но файберах, но не всегда хватает - для каждого чиха неудобно fiber pool или producer/consumer очередь создавать
тут даже в другом дело ... из за отсутствия такой "культуры" приходится везде проверять в лучшем случаем пколом .... неговоря уже о том что бы делать номальные graceful шатдауны последовательные и прочие прелести коих в асинхронной платформе до чертиков
но я кстати за 12 лет программирования на фьючерах и файберах пришёл к похожему выводу - и то и то нужно
сейчас ближайшая аналогия хукам из коробки - это некоторые триггеры, и то они только в ядре присутствуют, в библиотеках они напрочь отсутствуют, и узнать что чтото "перешло" или "собирается переходить" или "хочет перейти" в другое состояние практически нереально
в тему аналогий из go , такая штука как WaitGroups - странно что до сих пор в чате никто ничего похожего не спрашивал .. это кстати в тему dependency менеджера состояний
в тему аналогий из go , такая штука как WaitGroups - странно что до сих пор в чате никто ничего похожего не спрашивал .. это кстати в тему dependency менеджера состояний
там непонятно че делать, если кто-то закрыл канал/конд например. Меня тоже навеяло поведение гошного select, но пока вопросов по интерфейсу достаточно много
Скажите, может есть в какойто нибудь либе какого нибудь промис менеджера , что бы не писать страшных конструкций типа while not feature () do sleep(0.1) end а почеловечески сделать это все , чтобы не получалось fiber hell по аналогии с callback hell который был в ноде пока деферы и промисы не подвезли