ну... в конце концов, так или иначе event loop и green threads на равных event loop выигрывает в моих глазах в плане простоты написания кода из-за полного отсутствия параллельности (дебажить легче, проблемы очевиднее и прятаться им негде) green threads выигрывают в производительности позволяя параллелить бизнес-логику но в учётом что пользователь отдаёт себе отчёт в правильной синхронизации потоков (дебажить такое относительно сложнее)

коллега, вы троллите? какая такая простота в колбеках?

многие считают наоборот - в го ты асинхронный код пишешь как синхронный

однако обязан синхронизировать взаимодействие потоков, как не крути, race condition дебажить не айс

парни, вот расскажите, что думаете, Docker в прод тянуть надо или только для dev/test стоит юзать?

если у нас есть эвенты - есть и колбеки, бро

я имею ввиду в callback стиле никто уже давно не пишет, современные подходы такие как promises или reactive + streams

рейс кондишн ты и на евент лупе с пулом тредов можешь сделать

еще раз, есть эвент - есть его обработчик. который называется коллбэк

так чо там с докером?

я полностью согласен, что синхронный код в green thread'е читается легче, но тем не менее, асинхронное программирование тоже на месте не стояло последние годы

ну асинхронно уже везде можно писать в синхронном стиле

я бы сказал псевдо-синхронном

я полностью согласен, что синхронный код в green thread'е читается легче, но тем не менее, асинхронное программирование тоже на месте не стояло последние годы

потому-что читается сверху вниз но технически он асинхронен, лишь абстрагирован

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

ты в API шедулишь выполнение 2 функций, обе из которых работают допустим с одним и тем же глобальным динамическим массивом, евентлуп все это распараллеливает на пуле потоков и ты ИНОГДА видишь непредсказуемый результат

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

код твоей бизнес-логики тебе синхронизировать не нужно поскольку поток исполнения один единственный, то что происходит на pool'ах позади API тебя не касается, ты пользователь API

смотря какой абстракции API)

если пользователь используя event loop сам должен ещё и thread pool'е заботиться то с архитектурой платформы что-то не так)))

ну я про стиль же написания и чтения и говорю

http.get() .then(...) .then(...) .catch(...) вот тебе пример псевдо-синхронного кода, он читается как синхронный сверху вниз, последовательно, однако технически он асинхронный

ну и где тут эвентлуп?

ну я говорил что синхронный стиль асинхронного кода заставит его выполняться технически синхронно? вроде нет

это все те же гринтреды, с явным указанием yield (он там, где точка)

обычно в данном случае употребляется "секвенциально", не знаю как в русскоговорящей сфере

это все те же гринтреды, с явным указанием yield (он там, где точка)

есть хорошее русское слово - последовательно

в отличии от императивного - нет callback hell'а

есть зато control flow ад

всё-равно не совсем понимаю, планирование? в каком плане "планирование"??