В любом случае меня уговаривать не нужно, я всегда был, есть и буду на всех fw days конфах. Уровень организации этой конфы это лучше что я встречал на просторах восточной Европы)
Конференции нужны не для того чтобы узнать что-то новое, вон я сколько ключевых слов поназывал,  это любой может, а вот реальный опыт использования всего этого даст кучу полезной информации тем кто интересуется нужно ли лично ему тратить свое время на дальнейший разбор темы.

По поводу запуска - на докладе нужно прочитать секцию доки по запуску на крупных проектах, или пересказать открытые issue с репозитория?

Как работают -

Так не просто слушать про асинхронность, а в том КАК именно эта асинхронность принесла профит и почему без нее было не обойтись. В го все таки это из коробки, и он решает другой спектр задач. Когда мне надо было сделать быстрый реиндекс из постгреса в эластик, я просто взял го и на корутинах в несколько потоков ускорил из 10ч в 1. Можно было это сделать в пхп? Да. А как быть с проблемой того что теперь когда меняется структура бд, нужно менять код двух (типа микросервисов) аппов? Это ведь не нормально. Вот так и развиваться тема для доклада)

Для того, щоб на реальному проекті застосовувати якесь зі слів, що були згадані потрібно набивати свій досвід. Від того, що хтось скаже, що ddd супер або graphql гівно, то не переверне твою картину світу.

Нет, вот Леша много раз про стат. анализ рассказывал и вот сам признается что до сих пор тему не раскрыл. И про ограниченность того или иного анализатора (именно на практическом примере)? А перформанс померять?  Тут как раз у меня притензий никаких)

Я с вами во многих вещах согласен, которые вы написали вот за последний час. Мне тоже эти девопсинги уже в печенках сидят, на пхп конфах видеть эти богомерзкие aws, docker и прочее не хотел бы. Самому приходилось в это вникать только от безнадёги - когда на проекте нет девопса. Так хотелось бы последовать совету с ruhighload про инфраструктуру и облака - "отдайте это вашему девопсу, он разберется что с этим делать".

А вот про асинхронщину - самому очень интересно было бы услышать edge кейсы и обсудить это с кем-то. У меня как раз и несколько индексов в эластике и куча тяжелых долгих задач типа краулинга html выдачи, rabbitmq с 50+ очередями и к каждой по несколько консьюмеров под супервизордом. И всё это на php7 без утечек памяти (выстрадал в свое время, в некотором смысле) и без перезапуска работает от релиза одного спринта к релизу другого. Это edge кейс? Уже можно на конференцию идти рассказывать как у меня демон работает от 2 недель до месяца в среднем без перезапуска и ни 1 мб не утекает?

Задача про популейт индекса во много потоков у меня тоже возникала и есть готовое решение fos_elastica_bundle + enqueue_bundle. Типа кладет страницы для добавления в очередь (на самом деле любой транспорт подойдет, хоть файл), а потом в дофига консьюмеров достает и гребет. Всё из коробки - 2 консольных команды.

Когда объем таблицы вырастает пусть даже до 10 млн записей, а лучше до 100млн+ уже этого решения перестает хватать, уже приходится самому на более низком уровне подергать эту эластику и с помощью тех же очередей+консьюмеров (но мне больше понравился symfony/process с поднимающимися воркерами в зависимости от текущей нагрузки cpu/ram) добиться тех же х10 раз ускорения, что и с указанными вами горутинами и прочими зоопарками.

Мой месседж в чем - пыха последние года 4 уже хороша сама по себе нет никакой нужды городить зоопарки. Надо раз и навсегда разобраться с памятью, поюзать memory_get_usage(false) и memory_get_usage(true), попрофилировать и вуаля!

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

Что есть edge кейс, где пыхи7 перестаёт хватать и вот надо без вариков го брать? Ни разу не втыкался в ограничения самой пыхи. Чаще всего узкое место - это БД.

Дело не в "компилируемо", дело в развитой экосистеме

На счёт "узкое место бд" - узкое место I/O. И тут асинхронщина как раз спасает

Вот и я таких кейсов не знаю, я сам разгонял пыху так что мало не казалось, я не знаю каким надо быть амазоном или нетфликсом чтобы пыха была в чем то ограничением, в 80% случаев это i/o, в остальных 20% - кривые руки разработчика)

Имхо, про разное чуть говорим. Какая такая инфраструктура нужна для консьюмера очереди, что его многие рекомендуют писать на go? (Это ж демон просто)

Про I/O может недорос или не так понимаю, но про базу имел ввиду что надо под конкурентные запросы тюнить, когда консьюмеры чет в базу одновременно начинают писать.

Все познается в сравнении. Отладка, инструменты, риски. У того же го* риски ниже если нужна асинхронность ибо ты не сможешь застопорить сервак случайным циклом

Все равно не могу вдуплиться насчет i/o. То, что самые быстрые диски всё равно самое узкое место - это известно, но сейчас на серверах зачастую столько ram, что бывает можно установить такой заоблачный innodb_buffer_pool_size, что иногда и целая база может поместиться в ram. Чем больше буфер - тем меньше обращений к диску. В теории можно хоть всю бд поместить в ram, если она будет меньше допустимого innodb_buffer_pool_size.

А вот если например запустить много консьюмеров, которые будут что-то добавлять/изменять/удалять в одной таблице, вообще выполнять транзакции любые, то вырастет locktime, время ожидания освобождения блокировок, которое сам мускуль порождает. И сколько не профилировал запросы, i/o read/write конечно занимает время, но чаще всего меньше того locktime или самой выборки.

Или речь идет о том, что сами демоны обращаются к диску, что-то пишут на него или читают массово?

Очень интересная тема.

>> ибо ты не сможешь застопорить сервак случайным циклом

6+ лет пишу на пхп фреймворках и ни разу не доводилось увидеть, чтобы cli процесс уложил сервер целиком. Если с ним что-то не так, он вывалится по memory_limit рано или поздно... Или станет зомби процессом и его супервизорд попытается рестартануть.

Насчёт асинхрона и i/o, ситуации разные, когда ты просто хочешь разгрести очередь - наверное достаточно event loop'a, что-то делать над большим объемом данных - надо брать что-то многопоточное.
Продал бы душу за асинхронные и многопоточные генераторы (yield) в php)

$gen = fn() => foreach ($periods as $date) yield select * from big table;
$resultFromParallelRequests = iterator_to_array($gen);
Бац, и сразу за секунду 10 запросов к бд, а не по одному каждую секунду...

Вот именно эта простота подкупает в go, а не то что это нельзя сделать в php...)