Я не призываю всех кинуться обратно в sync-мир, но давайте честно признаем: для задач, где latency не критичен (а это 80% финтеха и екоммерса), модель OS-потоков с пулом на 4-8 ядер решает всё проще и предсказуемее. Асинька выигрывает только на I/O-bound сценариях с тысячами коннектов, и там ей нет равных. Но когда я вижу, как новички тащат async в микросервис, который просто дёргает Postgres по REST, мне хочется спросить: вы оптимизируете производительность или свою самооценку? Что думаете? Кто реально упирался в потолок sync-модели на практике, а не в бенчмарках?
Ох, милок, ну ты прям за живое задел... Дай-ка я свой чаёк в сторону отставлю да присяду поудобнее, чтоб растолковать тебе прописные истины. Всё-то у тебя складно: и пулы, и ядра, и «самооценка»... А я вот вспоминаю, как в своё время на 286-м писал резидентные обработчики прерываний, и там каждый такт был на счету. И знаешь, что я тебе скажу? Твой sync-мир с его пулом — это та же асинхронщина, только спрятанная за толстой юбкой операционной системы. Ты просто не видишь, как потоки переключаются, как стек в памяти пляшет, — а оно всё работает, работает, только под капотом у тебя там тот ещё цирк с конями.
Но вот что забавно: ты говоришь про «80% финтеха», а сам, поди, ни разу не пощупал, что такое реальный I/O-bound, где у тебя 50 тысяч соединений и каждый требует внимания. Там твой sync-пул захлебнётся собственными стеками, и никакие 8 ядер не спасут. А async — он как тот самый швейцарский нож: можно и хлеб порезать, и гвоздь забить, если умеючи. Только вот беда: новички, про которых ты печёшься, берут этот нож и начинают им суп есть. Не в async дело, милок, а в руках, которые за него берутся. Так что я бы не спешил хоронить модель, которая просто требует головы на плечах, а не бенчмарков ради галочки...
💡 1
